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1.0  INTRODUCTION 


This  chapter  explains  the  purpose  of  the  convention,  and  the  scope 
of  the  guidance  and  provides  an  explanation  of  how  to  use  the 
convention. 

1.1  PURPOSE  OF  THE  CONVENTION 

The  convention  provides  general  guidance  on  the  implementation 
of  American  National  Standards  Institute  (ANSI)  Accredited  Stand¬ 
ards  Committee  (ASC)  XI 2  electronic  data  interchange  (EDI) 
standards  within  automated  information  systems  (AIS)  and  on 
information  interchange  procedures  that  require  the  collection, 
reporting,  and/or  exchange  of  data  needed  to  perform  defense 
missions. 


1.2  SCOPE 

The  guidance  presented  here  may  be  used  by  organizational  ele¬ 
ments  of  the  DoD  community  and  by  non-DoD  organizations  that 
exchange  data  with  the  DoD  community  in  the  course  of  their 
business  relationships. 

The  DoD  community  encompasses  the  Military  Services,  Organiza¬ 
tions  of  the  Joint  Ctdefs  of  Staff,  Unified  and  Specified  Commands, 
Office  of  the  Secretary  of  Defense,  and  the  Defense  agencies.  (That 
community  is  collectively  referred  to  as  the  DoD  Components). 

Non-DoD  organizations  include  (a)  non-Govemmeut  organiza¬ 
tions,  both  commercial  and  nonprofit;  (b)  Federal  agencies  of  the 
United  States  Government  other  than  DoD;  (c)  local  and  state 
governments;  (d)  foreign  national  governments;  and  (e)  interna¬ 
tional  government  organizations. 

The  draft  convention  published  in  this  document  is  for  trial  use 
and  comment.  DoD  Components  must  submit  to  the  Office  of  the 
Under  Secretary  of  Defense  (Acquisition  and  Technology),  Com¬ 
puter-aided  Acquisition  and  Logistics  Support  and  Electronic  Data 
Interchange  [OUSD  (A  &  T)  CALS/EDI]  their  data  requirements 
that  are  not  covered  in  this  convention  as  soon  as  possible,  as 
indicated  in  Chapter  2.0,  Section  2.1. 

13  RESPONSIBLE  ENTITY 

(Reserved) 

1.4  HOW  TO  USE  THE  IMPLEMENTATION 
CONVENTION 

The  main  topics  and  structures  of  this  document  conform  to  the 
EDI  Implementation  Reference  Manual  Guidelines  document  that 
was  developed  by  a  task  group  of  the  subcommittee  on  education 
and  implementation  of  the  ASC  XI 2.  The  purpose  of  having 
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agreed-upon  topics  and  structure  is  to  facilitate  reference  by  the 
many  industry  and  DoD  personnel  who  are  involved  in  implement¬ 
ing  the  uniform  standards  for  electronic  interchange  of  business 
transactions. 

1.4.1  Conventions,  Standards,  and  Guidelines 

The  terms  conventions,  standards,  and  guidelines  are  used 
throughout  this  document  and  are  ttefmed  as  follows: 

•  Conventions  are  the  common  practices  and/or  interpretations 
of  the  use  of  ASC  X12  standards  Conventions  define  what  is 
included  in  a  specific  implementation  of  an  ASC  X 1 2  standard. 

•  Standards  are  the  technical  documentation  approved  by 
ASC  XI 2;  specifically,  transaction  sets,  segments,  dau  ele¬ 
ments,  code  sets,  and  interchange  control  structure.  Standards 
provide  the  structure  for  each  ASC  X12  document. 

•  Guidelines  are  instructions  on  the  use  of  EDI.  They  provide 
additional  information  to  assist  in  conducting  EDI.  Guidelines 
are  intended  to  provide  assistance  and  should  not  be  your  sole 
source  of  information. 

1 .4.1 .1  Who  Oevoiops  the  Conventione? 

Conventions  result  from  a  joint  effort  by  business,  technical,  and 
EDI  ASC  XI2  standards  experts.  The  business  data  requirement 
is  defined,  a  transaction  set  is  selected,  and  the  data  requirement 
is  then  identified  with  data  elements  in  the  transaction  set.  A 
convention  is  usually  developed  before  any  conqiuter  EDI  systems 
developnttnt  work  and  serves  as  a  design  document  when  the 
development  process  begins. 

1.4.1.2  Why  Um  a  Conwntion? 

To  create  an  ASC  X12  transaction,  a  user  must  know  the  data 
requirements,  understand  the  ASC  X12  standard,  and  be  able  to 
use  that  information  to  develop  an  interface  program  between  the 
computer  application  and  the  ASC  X12  translator.  The  necessary 
information  to  perform  that  task  is  contained  in  the  convention 
document.  Users  who  follow  the  convention  will  create  a  transac¬ 
tion  set  that  all  DoD  users  undentand. 

1.4.1 .3  Who  NMds  a  Convention? 

System  analysts  and  application  programmers  who  plan  to  create 
or  read  ASC  X12  transactions  use  a  convention  to  aid  in  interface 
software  design.  The  convention  will  help  the  programmer  and 
analyst  identify  where  their  application  data  requirement  should  be 
carried  in  an  ASC  X12  transaction  set. 

1 .4.4.4  Can  I  Develop  a  Convention? 

Conventions  already  exist  for  some  of  the  most  common  business 
practices.  Copies  of  existing  conventions  can  be  acquired  through 
your  organization’s  EDI  coordinator  at  the  start  of  an  EDI  project. 
If  you  find  no  conventions  for  the  business  practice  you  are  about 
to  implement,  your  EDI  coordinator  should  contact  the  CALS 
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EvaluatioD  and  Integration  Office.  See  Chapter  2.0,  Maintenance, 
Section  2.1  for  the  point  of  contact. 

1.4.2  Documentation  of  Conventions 

Conventions  are  adopted  from,  and  are  intended  to  be  in  confor¬ 
mance  with,  ANSI  ASC  X12  standards  or  ASC  X12  Draft  Stand¬ 
ards  for  Trial  Use  (DSTU). 

1. 4.2.1  Transaction  Set 

Figure  1.4-1  provides  an  example  of  a  transaction  set  table.  The 
transaction  set  defines  information  of  business  or  strategic  sig¬ 
nificance  and  consists  of  a  transaction  set  header  segment,  one  or 
more  data  segments  in  a  specified  order,  and  a  transaction  set 
trailer  segment.  The  actual  ASC  X12  standard  as  it  appears  in  t*'e 
official  ASC  X12  sundards  manual  is  presented  on  the  right  side 
of  the  page.  That  standard  also  includes  both  syntax  notes  and 
comments.  The  specific  DoD  usage  designator  is  presented  on  the 
left  side  of  the  page. 

The  designation  “N/U"  stands  for  "not  used”  and  appean  in  the 
left  column  if  DoD  does  not  use  the  specific  segment.  A  page 
number  will  appear  if  the  segment  is  used. 

1. 4.2.2  Transaction  Set  Segment 

Figure  1.4-2  is  an  example  of  a  transaction  set  segment. 

DoD  usage  is  specified  on  the  left  side  of  the  page.  For  identifier 
(ID)-type  dau  elements,  acceptable  code  values  are  listed  on  the 
right  side  of  the  page  under  the  definitions  of  the  element. 

DoD  notes,  reflecting  how  the  convention  is  to  be  used  appear  on 
the  right  side  of  the  page  at  the  segment  level  or  the  data  element 
level. 

The  following  definitions  are  for  use  in  interpreting  the  data 
element  requirement  designators  in  the  DoD-specific  segment 
directory  section  of  the  convention.  For  ASC  X12  usage,  see  the 
definitions  in  XI2.6  Application  Control  Structure. 

•  Mandatory 

Mandatory  data  elements  are  defined  by  ASC  X12. 

•  Optional 

Optional  data  elements  are  used  at  the  discretion  of  the  sending 
party  or  are  based  upon  mutual  agreement  between  trading 
partners. 

•  Required 

Required  data  elements  are  considered  optional  under 
ASC  X12  rules  but  are  required  by  DoD  decision. 

•  Recommended 

Recommended  data  elements  are  considered  optional  under 
ASC  X12  rules  and  by  the  DoD,  but  the  industry  recommends 
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824  Application  Advice 


MM*  »aca 


10  010 
12  020 
13  030 

NAJ  040 
N/U  OSO 
N/U  060 


14  070 

15  080 

16  090 


This  Standard  orovides  the  format  and  establishes  the  data  contents  of  the 
Application  Advice  Transaaon  Set  (824)  within  the  context  of  an  Electronic 
Data  interchange  (EDI)  environment  This  transaction  set  provides  the  ability 
to  report  the  results  of  an  application  system  s  data  content  edits  of 
transaction  sets  The  results  of  editing  transaction  sets  can  be  reported  at  the 
functional  group  and  transaction  set  level,  m  either  coded  or  free-form  format 
It  IS  designed  to  accomodate  the  business  need  of  reporting  the  acceptance, 
refection  or  acceptance  wEh  change  of  any  transaction  set.  The  Application 
Advice  should  not  be  used  in  place  of  a  transaction  ..et  designed  as  a 
specific  response  to  another  trahsaction  set  (eg.,  purchase  order 
acKnowledgement  sent  in  response  to  a  purchase  order). 


Table  1 

Ha*  NMM 


ST  Transaann  Set  Header 
BGN  Beginning  Segment 

LOOeV'NI 
Ni  Name 

N2  Additional  Name  information 

N3  Address  information 

N4  Geographic  Location 

REF  Reference  Numbers 

PER  Administrative  Communications  Contact 


OAtl  •  JANUARY  St  tees 


Figure  1.4-1  Example  of  a  Transaction  Set  Table 
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I  SBgmsnt:  BGN  Ssflinnlng  SAgmstit 

LbvbI:  Header 

!  !  Loop:  _ 

uandAiery  ,  UssgB:  Mandatory 

MbxUsb:  1 

PurpoBS:  To  indicate  the  beginning  o>  a  transact'on  set 
Syntax:  if  BGNOS  is  used.  BGN04  is  required 
Commants:  >.  BGN02  is  the  Transaction  Set  Reference  Number 

2.  BGN03  IS  the  Transaction  Set  Date 

3.  BGN04  IS  the  Transaction  Set  Time 

4.  BGNOS  IS  the  transactnn  set  time  qualifier 

Data  Efement  Summafy _ 


HaneaMry 


ConeMaaal 


BONOt  353  Trafieeetfen  Set  Purpeee  Cede  M  ID  2/3 

Coda  Marmfying  purpose  of  transacnon  sat. 

00  Orginal 
01  Cancellation 
04  Change 
12  Not  Processed 

BQN02  12T  Reference  Number  N  AN  1/30 

Reference  number  or  Mermfcation  number  as  defined  for  a  particuiar 
Transaamn  Set.  or  as  specified  by  the  Reference  Number  Qualifier. 

BONOa  373  Data  M  DT  M 

Date  (YYMMOO). 

BON04  337  Time  C  TM  4/4 

Time  ei^rassed  m  24-hour  dock  time  (HHMM.  time  range:  0000  though  2350). 

BnpfamentaNon  Nela: 

UuHHMH. 

BQN05  623  Tbna  Cede  O  10  2/2 


OABI  •  JANUARY  3B  II 


Figure  1.4-2  Example  of  a  Transaction  Set  Segment 
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their  use  to  facilitate  EDI.  Most  companies  in  the  industry 
are  expected  '>  use  this  data  element. 

•  Not  Used 

“Not  Used’’  data  elements  are  those  that  DoD  does  not  use. 

•  Conditional 

Conditional  data  elements  depend  on  the  presence  of  other  oata 
elements  in  the  transaction  set. 
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2.0  MAINTENANCE 


This  chapter  describes  the  procedures  for  maintaining  the  OoD 
conventions.  It  also  presents  a  section  on  version/release  timing. 

2.1  MAINTAINING  CONVENTIONS 

( Reserved } 

2.2  VERSION/RELEASE  TIMING 

Identification  of  the  official  “version”  of  a  standard  is  critical  to 
the  successful  interchange  of  information.  Each  participant  must 
be  able  to  send  and  receive  the  same  version  to  ensure  the  accuracy 
of  the  information  exchanged. 

The  version  is  transmitted  as  a  1 2-character  code  in  the  Functional 
Group  Header  segment  (GS)  in  Data  Element  #480,  Ver¬ 
sion/Release/Industry  ID.  This  12-character  code  is  used  by 
ASC  X12  as  follows- 

Positioa  Content 

1-3  Version  number 

4-5  Release  level  of  version 

6  Subrelease 

7-12  DoD/lndustry  or  Trade  Association  ID 

ASC  XI 2  assigns  the  codes  in  Position.  1  through  6. 

The  version  number  (001,  002,  003,  etc.)  will  change  only  after  an 
official  public  review  cycle  leads  to  republication  of  a  new 
American  National  Standard. 

The  release  level  of  each  new  major  version  (Positions  4-6  in  the 
Functional  Group  Header)  will  begin  at  “000”  and  increased  by  1 
for  each  new  ASC  X12  approved  publication  cycle,  usually  once 
a  year.  The  fourth  and  fifth  characters  designate  the  release  and 
the  sixth  character  designates  the  subrelease. 

The  DoD  Industry  Trade  Association  ID  (Position  7-12)  is  used 
to  identify  conventions.  For  this  suffix,  DoD  will  use  “DoD_” 
with  the  10th  character  identifying  successive  publications.  The 
1 1th  and  12th  characters  may  be  used  by  the  Military  Departments 
or  Defense  agencies. 

DoD  conventions  for  using  ASC  X12  standards  are  published 
annually.  Conventions  developed  for  each  release  will  be  main¬ 
tained  for  4  years.  Military  Services  and  DoD  agencies  will 
determine  which  release  to  use  on  the  basis  of  business  need  but 
will  not  use  any  release  more  than  4  years  old  without  approval 
by  the  OUSD  (A  &  T)  CALS/EDI. 
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_ ANSI  ASC  X12  VERSION.  RELEASE  003030DOD_ 

3.0  DoD  CONVENTIONS  FOR  USING 
ASC  X12  TRANSACTION  SETS 

This  chapter  defines  the  DoD  transaction  set  conventions.  It 
includes  the  instructions  for  implementing  the  control  structure  and 
definitions  of  the  usage  indicators  and  applicable  codes. 

3.1  INTRODUCTION 

The  power  of  the  ASC  XI 2  standard  is  -n  its  building  block 
concept,  which  standardizes  the  essential  elements  of  business 
transactions.  The  concept  is  analogous  to  a  "standard  bill  of 
materiels  and  the  construction  specifications,”  which  gives  the 
architect  flexibility  in  what  can  be  designed  with  standardized 
materiels  and  procedures.  The  EDI  system  designer,  like  the  ar¬ 
chitect,  uses  the  ASC  XI 2  standards  to  build  business  transactions 
that  are  often  dif*"''rent  because  of  their  function  and  yet  utilize  the 
ASC  X12  standards.  The  ‘‘bill  of  materiels  and  the  construction 
specification”  of  ASC  XI 2  are  the  standards  found  m  the  published 
technical  documentation. 

AbC  X12.3  -  The  Data  Elem  nt  Dictionary  spcc.fies  the  data 
elements  used  in  the  construction  of  the  segments  ti  at  comprise 
the  transaction  sets  developed  by  ASC  XI 2. 

ASC  X12.5  -  The  interchange  Control  Structure  provides  the 
interchange  control  segment  (also  called  an  envelope)  of  a  header 
and  trailer  for  the  electronic  interchange  through  a  data  transmis¬ 
sion;  it  also  provides  a  structure  to  acknowledge  the  receipt  and 
processing  of  the  envelope. 

ASC  XI  2.6  -  The  Application  Control  Structure  defines  the  basic 
control  structures,  syntax  rules,  and  semantics  of  EDI. 

ASC  X12.22  -  The  Data  Segment  Directory  provides  the  defini¬ 
tions  and  specifications  of  the  segments  used  in  the  construction 
of  transaction  sets  developed  by  ASC  XI 2. 

The  DoD  convention  in  Section  3.4  conforms  to  the  above  stand¬ 
ards,  and  each  transaction  set  is  a  complete  document  to  the  extent 
possible.  For  further  clarification  of  acronyms,  abbreviations,  and 
codes,  refer  to  ASC  XI 2  published  technical  documentation.  For 
copies,  contact  either  the  OUSD  (A  &  T)  CALS/EDI  or  the  Data 
Interchange  Standards  Association,  Inc.,  Suite  35.5,  1800  Diagonal 
Road,  Alexandria,  VA  22314. 

3.2  CONTROL  SEGMENTS 

In  addition  to  the  communication  control  structure,  the  EDI  structure 
provides  the  standards  user  with  multiple  levels  of  control  to  ensure 
data  integrity.  It  does  so  by  using  header  and  trailer  control  segments 
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designed  to  identify  uniquely  the  start  and  end  of  the  interchange 
functional  groups  arvl  transaction  sets.  The  relationship  of  these 
control  segments  is  shown  in  Figure  3.2-1.  Control  Segment 
specifications  are  defined  in  Section  3.2.2. 

3.2.1  Description  of  Use 

The  interchange  header  and  trailer  segments  surround  one  or  more 
functional  groups  or  interchange-related  control  segments  and  per¬ 
form  the  following  functions: 

•  Define  the  data  element  se^. orators  and  data  segment  ter¬ 
minators 

•  Identify  the  sender  and  receiver 

•  Provide  control  information 

•  Allow  for  authorization  and  security  information. 

The  Interchange  Acknowledgment  Segment  is  used  to  acknowledge 
one  interchange  header  and  trailer  envelope  where  the  envelope 
surrounds  one  or  more  functional  groups.  (No  acknowledgment  is 
made  for  the  interchange  acknowledgment.) 

The  interchange  control  number  value  in  the  acknowledgment 
(TAl  segment)  is  the  same  as  that  for  the  ISA  segment  that  is 
being  acknowledged.  The  control  number  serves  as  a  link  between 
the  interchange  header  and  trailer  and  the  acknowledgment  of  that 
header  and  trailer. 

The  interchange  acknowledgment  does  not  report  any  stams  on  the 
functional  groups  contained  in  the  interchange  and  is  separate 
from  the  communication  system’s  error  procedures. 

The  preparer  of  the  interchange  header  and  trailer  indicates  the 
level  of  acknowledgment  in  Data  Element  113,  Acknowledgment 
Requested.  If  an  acknowledgment  is  requested,  then  the  recipient 
must  return  an  acknowledgment.  If  not  requested,  none  should  be 
given. 

The  interchange  acknowledgment  control  segments  ate  placed  after 
the  interchange  header  and  before  the  first  function^  group  or 
before  the  interchange  trailer  if  there  are  no  functional  groups. 

Control  segments  are  standard  for  all  implementation  conventions 
produced  for  the  Department  of  Defense.  Some  codes  associated 
with  individual  data  elements  within  the  control  segments  are 
unique  to  the  individual  transaction  set.  Others,  identify  the  ANSI 
version  and  release  in  which  the  convention  is  written. 
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Mandatory 


Mandatory 


Mandatory 


Mandatory 


Mandatory 


Mandatory 


Mandatory 


Segment:  ISA  Interchange  Control  Header 

Purpose:  To  start  and  identify  an  interchange  of  one  or  more  functional  groups 
and  interchange-related  control  segments. 

Data  Element  Summa 


ISA01  101  Authorization  Information  Qualifier  M  ID  2/2 

Code  to  identify  the  type  of  information  in  the  Authorization  Information. 

00  No  Authorization  Information  Present  (No  Meaningful  Information  in  102) 

ISA02  102  Authorization  Information  M  AN  10/10 

Information  used  for  additional  identification  or  authorization  of  the  sender  or  the 
data  in  the  interchange.  The  type  of  information  is  set  by  the  Authorization 
Information  Qualifier. 

Implementation  Note: 

If  no  authorization  information  is  agreed  to  by  trading  partners,  fill  field  with  blanks. 

ISA03  103  Security  Information  Qualifier  M  ID  2/2 

Code  to  identify  the  type  of  information  in  the  Security  Information. 

01  Password 

ISA04  104  Security  Information  M  AN  10/10 

This  is  used  for  identifying  the  security  information  about  the  sender  or  the  data 
in  the  interchange.  The  type  of  information  is  set  by  the  Security  Information 
Qualifier. 

Implementation  Note: 

An  agreed  upon  password.  If  no  security  information  is  agreed  to  by  trading  partners,  fill  field  with  blanks. 


ISA06 


ISA05  105  Interchange  ID  Qualifier  M  ID  2/2 

Qualifier  to  designate  the  system/method  of  code  structure  used  to  designate  the 
sender  or  receiver  ID  element  being  qualified. 

ZZ  Mutually  Defined 
Code  Value  Implementation  Note: 

An  agreed  upon  designation  ofDoD  Activity  Address  Code  (DoDAAC)  or  other  code  coordinated 
with  the  value-added  network  (VAN). 

ISA06  106  Interchance  Sender  ID  M  ID  15/15 

Identifioatii  ;<  r  ode  published  by  the  sender  for  other  parties  to  use  as  the 
receiver  ID  to  route  data  to  them.  The  sender  always  codes  this  number  in  the 
sender  ID  element. 

Implementation  Note: 

Department  of  Defense  activities  use  DoD  Activity  Address  Code  (DoDAAC)  or  other  code  coordinated  with 
the  value-added  network  (VAN).  Non-DoD  activities  use  identification  code  qualified  by  ISA05  and 
coordinated  with  the  VAN. 

ISA07  105  Interchange  ID  Qualifier  M  ID  212 

Qualifier  to  designate  the  system/method  of  code  structure  used  to  designate  the 
sender  or  receiver  ID  element  being  qualified. 

ZZ  Mutually  Defined 


BASEUNE  AS  OF:  JULY  9, 1993 


DI22  •  3.0.7 


DEPARTMENT  OF  DEFENSE 

DRAFT  IMPLEMENTATION  CONVENTION 


001  •  CONTROL  SEGMENTS 
ISA  •  INTERCHANGE  CONTROL  HEADER 


841  FURNISH 

ANSI  ASC  X12  VERSION/RELEASE  003030DOD 


Mandatory 


Mandatory 


Mandatory 


Mandatory 


Mandatory 


Mandatory 


Mandatory 


Mandatory 


Code  Value  Implementation  Note: 

An  agreed  upon  designation  of  DoD  Activity  Address  Code  (DoDAAC)  or  other  code  coordinated 
with  the  value-added  network  (VAN ). 

ISA08  107  Interchange  Receiver  ID  M  ID  15/15 

Identification  code  published  by  the  receiver  of  the  data.  When  sending,  it  is 
used  by  the  sender  as  their  sending  ID,  thus  other  parties  sending  to  them  will 
use  this  as  a  receiving  ID  to  route  data  to  them. 

Implementation  Note: 

Department  of  Defense  activities  use  DoD  Activity  Address  Code  (DoDAAC )  or  other  code  coordinated  with 
the  value-added  network  (VAN).  Non-DoD  activities  use  identification  code  qualified  by  ISA05  and 
coordinated  with  the  VAN. 

ISA09  108  Interchange  Date  M  DT  6/6 

Date  of  the  interchange. 

Implementation  Note: 

Assigned  by  translation  software.  YYMMDD 

ISA10  109  Interchange  Time  M  TM  4/4 

Time  of  the  interchange. 

Implementation  Note: 

Assigned  by  translation  software.  HHMM 

ISA11  110  Interchange  Control  Standards  Identifier  M  ID  1/1 

Code  to  identify  the  agency  responsible  for  the  control  standard  used  by  the 
message  that  is  enclosed  by  the  interchange  header  and  trailer. 

U  U.S.  EDI  Community  of  ASC  XI 2,  TDCC,  and  UCS 

ISA12  111  Interchange  Control  Version  Number  M  ID  5/5 

This  version  number  covers  the  interchange  control  segments  and  the  functional 
group  control  segments. 

00303  Draft  Standard  for  Trial  Use  Approved  for  Publication  by  ASC  XI 2  Procedures 
Review  Board  Through  October  1992 

Code  Value  Implementation  Note: 

Version  ID  as  defined  or  agreed  upon  by  the  trading  partners. 

ISA  13  112  Interchange  Control  Number  M  NO  9/9 

This  number  uniquely  identifies  the  interchange  data  to  the  sender.  It  is  assigned 
by  the  sender.  Together  with  the  sender  ID  it  uniquely  identifies  the  interchange 
data  to  the  receiver.  It  is  suggested  that  the  sender,  receiver,  and  all  third  parties 
be  able  to  maintain  an  audit  trail  of  interchanges  using  this  number. 

ISA14  113  Acknowledgment  Requested  M  ID  1/1 

Code  sent  by  the  sender  to  request  an  interchange  acknowledgment. 

0  No  Acknowledgment  Requested 
1  Interchange  Acknowledgment  Requested 

ISA15  114  Test  Indicator  M  ID  1/1 

Code  to  indicate  whether  data  enclosed  by  this  interchange  envelope  is  test  or 
production. 

P  Production  Data 
T  Test  Data 
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Mandatory 


Cod0  Value  Implementation  Note: 

Assigned  by  translation  software. 

ISA16  115  Subelement  Separator  M  AN  1/1 

This  is  a  field  reserved  for  future  expansion  in  separating  data  element 
subgroups.  (In  the  interest  of  a  migration  to  international  standards,  this  should 
be  different  from  the  data  element  separator). 

Implementation  Note: 

Use  character 
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Segment:  GS  Functional  Group  Header 

Purpose:  To  indicate  the  beginning  of  a  functional  group  and  to  provide  control 
information 

Syntax:  The  data  interchange  control  number  (GS06)  in  this  header  must  be 
identical  to  the  same  data  element  in  the  associated  Functional  Group 
Trailer  (GE02). 


Comment:  A  functional  group  of  related  transaction  sets,  within  the  scope  of  X12 

standards,  consists  of  a  collection  of  similar  transaction  sets  enclosed  by 
a  functional  group  header  and  a  functional  group  trailer. 


Mandatory 


Mandatory 


_ Data  Element  Summary _ 

HtF.  OAT*  _ 

OiS.  CLBiOfT  NAtti  _ ATTWOUTtS 

GS01  479  Functional  Identifier  Code  M  ID  2/2 

Code  identifying  a  group  of  application  related  T ransaction  Sets. 

Implementation  Note: 

Choose  the  code  value  appropriate  to  the  information  content  of  the  functional  group.  See  XI 2  Dictionary  for 
source  code  list. 

SP  Specifications/Technical  Information  (841) 

GS02  142  Application  Sender’s  Code  M  AN  2/15 

Code  identifying  party  sending  transmission.  Codes  agreed  to  by  trading 
partners. 

Implementation  Note: 

Department  of  Defense  activities  use  DoD  Activity  Address  Code  (DoDAAC).  Non-DoD  activities  use 
ideraification  code  assigned  by  DoD  activity.  For  increased  security,  non-DoD  code  should  differ  from  that 
used  in  ISA06. 


Mandatory 


GS03  124  Application  Receiver’s  Code  M  AN  2/15 

Code  identifying  party  receiving  transmission.  Codes  agreed  to  by  trading 
partners. 

Implementation  Note: 

Department  of  Defense  activities  use  DoD  Activity  Address  Code  (DoDAAC).  Non-DoD  activities  use 
identification  code  assigned  by  DoD  activity.  For  increased  security,  non-DoD  code  should  differ  from  that 
used  in  ISA08. 


Mandatory 


Mandatory 


Mandatory 


Mandatory 


GS04 

373 

Date 

Date  sender  generated  a  transaction  set. 

M 

DT 

6/6 

GS05 

337 

Time 

Time  expressed  in  24-hour  clock  time. 

M 

TM 

4/6 

GS06 

28 

Group  Control  Number 

Assigned  number  originated  and  maintained  by  the  sender. 

M 

NO 

1/9 

Implementation  Note: 

Assigned  by  translation  software. 

GS07 

455 

Responsible  Agency  Code 

M 

ID 

1/2 

Code  used  in  conjunction  with  Data  Element  480  to  identify  the  issuer  of  the 
standard. 


X  Accredited  Standards  Committee  X1 2 
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Mandatory 


Code  Value  Implementation  Note: 

Indicates  that  an  ANSI  X12  standard  is  being  transmitted. 

GS08  480  Version/Release/Industry  ID  Code  M  ID  1/12 

Code  indicating  the  version,  release,  subrelease  and  industry  identifier  of  the  EDI 
standard  being  used.  Positions  1-3,  version  number;  positions  4-6,  release  and 
subrelease  level  of  version;  positions  7-12,  industry  or  trade  association  identifier 
(optionally  assigned  by  user). 

003030  Draft  Standards  Approved  by  ASC  X12  Through  October  1 992. 

Code  Value  Implementation  Note: 

Code  value  agreed  to  by  trading  partners.  See  X12  Dictionary  for  source  code  list. 
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Segment:  GE  Functional  Group  Trailer 

Purpose:  To  indicate  the  end  of  a  functional  group  and  to  provide  control 
information 


Syntax:  The  data  interchange  control  number  (GE02)  in  this  trailer  must  be 

identical  to  the  same  data  element  in  the  associated  Functional  Group 
Header  (GS06). 

Comment:  The  use  of  identical  data  interchange  control  numbers  in  the  associated 
functional  group  header  and  trailer  is  designed  to  maximize  functional 
group  integrity.  The  control  number  is  the  same  as  that  used  in  the 
corresponding  header. 


Mandatory 


Mandatory 


_ Data  Element  Summary _ 

MCF.  DATA 

OIS.  ILBWKT  HAMI _ ATnWUTtS 

GE01  97  Number  of  Transaction  Sets  Included  M  NO  1/6 

Total  number  of  transaction  sets  included  in  the  functional  group  or  interchange 
(transmission)  group  terminated  by  the  trailer  containing  this  data  element. 

Iniplementaiion  Note: 

Assigned  by  translation  software. 

GE02  28  Group  Control  Number  M  NO  1/9 

Assigned  number  originated  and  maintained  by  the  sender. 

Implementation  Note: 

Assigned  by  the  translation  software.  This  control  number  must  match  the  control  number  of  the  preceding 
GS06  corurol  number. 
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Segment:  lEA  interchange  Control  Trailer 

Purpose*  To  define  the  end  of  an  interchange  of  one  or  more  functional  groups 
and  interchange-related  control  segments 


Mandatory 


Mandatory 


_ Data  Element  Summary _ 

REF.  DATE 

OES _ ELEMEHT  NAME _ ATT—UTES 

IEA01  116  Number  of  Included  Functional  Groups  M  NO  1/5 

A  count  of  the  number  of  functional  groups  included  in  a  transmission. 

Implementation  Note: 

Assigned  by  translation  software. 

IEA02  112  Interchange  Control  Number  M  NO  9 '9 

This  number  uniquely  identifies  the  interchange  data  to  the  sender.  It  is  assigned 
by  the  sender.  Together  with  the  sender  ID  it  uniquely  identifies  the  interchange 
data  to  the  receiver.  It  is  suggested  that  the  sender,  receiver,  and  all  third  parties 
be  able  to  maintain  an  audit  trail  of  interchanges  using  this  number. 

Implementation  Note: 

Assigned  by  the  translation  software.  This  control  number  must  match  the  number  that  occurs  in  ISAI3. 
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ASCX12m  FORMAT 

DEFINITION 

ST*841*0001 

This  is  nn  841  transaction  Mt  with  a  control  numhcr  of  0001. 

SPI*W*TN*84IFUR001»*«*00*ER*06  n/I 

The  data  being  provided  have  a  government  claasification  of 
secret  (Code  93)  and  a  commercial  protection  levd  of  company 
proprietary  (Code  06).  The  transaction  set  reference  number 
(Code  TN)  is  841FUR001.  This  is  an  original  transmission 
(Code  00)  of  an  Engiiiecring  Change  Proposal  (Code  ER). 

REF*CT*N0001W2C1357  n/I 

The  contract  number  (Code  CT)  to  which  this  ECP  pertains  is 
N0001992CI357. 

DTM*092«92Q2l4ii/I 

The  contract  date  (Code  092)  is  February  14, 1992. 

REF«39*MDAC789  nA 

The  ECP  proposal  (Code  39)  number  is  MDAC789. 

DTM*ZZZ*93(»709n/l 

The  date  of  the  ECP  proposal  (Code  ZZZ)  is  July  9, 1993. 

N1*SE**33*MD1234  nA 

The  selling  party  (Code  SE)  is  identified  by  CAGE  code  (code 
33)MDMD1234. 

N1*BY**10*N00019  n/l 

The  buying  activity  (Code  BY)  b  hkntillcd  by  DoD/LAC 
(Codel0)N00019. 

PER*IC*  Jodie  Fostcr«TE«71434S6789  n/I 

The  point  of  contact  (Code  1C)  at  the  originator's  activity  b 

Jodie  Foster.  Her  tekphone  number  (Code  TE)  b  714-3^- 
6789. 

HL*l**A*0n/l 

Thb  b  the  first  iteration  of  the  HL  Loop  as  specified  by  the 
number  1.  It  has  no  parent  The  hbrarchkal  ievel  b  the 
assembly  (Code  A).  It  has  no  subordinate  kvel  (Code  0). 

SP1*93*DG*MDAC9DW789***J***06 

n/l 

The  drawing  (Code  DG)  number  b  MDAC9DW789.  The 
drawing  b  being  proposed  (Code  J)  by  one  trading  partner  to 
another.  It  b  claadfied  government  secret  (Code  93)  and  has  a 
commercial  protection  kvel  of  company  proprietary  (Code 

06). 

LIN**F7*RGMM*FS*3790012345678*PD 
*Altimeter  n/l 

The  end  item  appiicatioa  (Code  FT)  reference  number  b 

RGM84.  The  national  stod(  number  (Code  FS)  b 

3790012345678.  The  item  description  b  Altimeter. 

Nl*ZE**33*EnV9876  n/l 

The  manufbeturer  (Code  ZE)  of  the  assembly  has  a  CAGE 
code  (Code  33)  of  HW9876 
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MSG*Tlw  proposed  chanfe  adds  a  Free  form  text  related  to  the  data  item, 

mountiiig  bracket  at  the  rear  of  the 
assembly  n/l 

EFI*93**9N*3  J*TruiikCAD*3  J*MIL>R<  The  data  provided  in  the  BIN  aecment  arc  rlatfiBed 
28002*3.3*TRIM*AH*DRAW  n/l  (ovemment  secret  (Code  93).  The  seaulty  techniqae  (Code 

9N)  is  encryption.  It  was  created  nsiaf  an  appiteiudon 
program  kMwn  as  TrankCad,  Versioo  33.  The  traasCer 
format  used  is  Raster  (MIL>R-280Q2),  Version  3J.  TbelHr 
was  compressed  using  the  ITUM  program.  Version  3  J.  The 
drawing  sixe  to  be  plolted  to  8.5  inches  x  11.0  inches  (Code 
AH).  The  name  of  the  Ok  containing  this  data  is  DRAW. 

BIN*1109Q8* _ n/l  The  binary  data  trananitted  arc  110908  octets  in  length. 

SE*17*0001  This  transaction  set,  whose  control  number  to  0001,  consists  of 

17  segments. 


X0.18 
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841  Specifications/Technical  Information 

This  Draft  Standard  for  Trial  Use  contains  the  format  and  establishes  the  data  contents  of  the 
Specifications/Technical  Information  Transaction  Set  (841)  for  use  within  the  context  of  an 
Electronic  Data  Interchange  (EDI)  environment  The  transaction  set  can  be  used  to  transmit 
specifications  or  technical  inforntabon  between  trading  partners.  It  can  be  used  to  allow  EDI 
trading  partners  the  ability  to  exchange  a  complete  or  partial  technical  description  of  a  product, 
process,  service,  etc.  over  the  same  path  as  any  other  EDI  transaction.  The  detail  area  can 
include  graphic,  text,  parametric,  tabular,  image,  spectral,  or  audio  data.  A  transmission  includes 
identification  information  to  assist  the  receiver  in  interpreting  and  utilizing  the  information 
included  in  the  transaction. 

Further  action  as  a  consequence  of  the  receipt  and  initial  processing  of  the  specification  or  other 
technical  data  may  or  may  not  require  human  intervention.  The  transmission  and  receipt  of  the 
data  may  require  private  agreement  between  the  tradirtg  partners  to  automate  the  receipt  of  the 
data. 

The  total  transaction  must  be  in  the  general  form  of  all  ASC  X1 2  transactions  so  that  an  EDI 
computer  system  will  be  able  to  automatically  recognize  it  as  a  Specification/Technical 
Information  Transaction  Set  and  pass  it  on  for  processing  of  the  data  itself.  The  transaction  set 
is  not  media  dependent. 

The  detail  area  of  the  Specitication/Technical  Information  Transaction  Set  provides  a  structure 
which  allows  for  the  exchange  of  a  variety  of  specification  information.  For  example,  if  the 
transaction  contains  information  describing  a  complete  assembly,  it  would  be  necessary  to 
include  the  assembly  mode),  the  models  for  each  of  the  individual  parts,  and  the  associated 
specifications.  In  the  case  of  a  process  it  may  be  necessary  to  transmit  the  specification  of  the 
product  along  with  the  specifications  of  the  process  and  raw  materials.  This  transaction  set  can 
also  be  linked  to  other  tiansaction  sets. 

This  transaction  set  is  not  limited  to  a  specific  transmission  protocol  and  uses  other  standards  as 
applicable  where  they  do  not  conflict  with  these  requirements  for  specification  transaction. 

Implementation  Note 

This  draft  implementation  convention  is  designed  to  permit  the  transmission  of  specifications/ technical 
information  in  binary  form  between  government  facilities  and  between  government  and  contractor  facilities. 


Table  1 


PAGE* 

POS.* 

SEG.  ID 

NAME 

REa  DBS. 

MAX  USE 

LOOP  REPEAT 

5 

010 

ST 

Transaction  Set  Header 

M 

1 

tOOPJO-SPI 

>1 

6 

020 

SPI 

Specification  Identifier 

M 

1 

N/U 

030 

RDT 

Revision  Date/Time 

0 

>1 

8 

040 

NTE 

Note/Special  Instructior 

O 

>1 

N/U 

050 

XI 

Export  License 

0 

1 

N/U 

060 

X2 

Import  License 

O 

1 

N/U 

070 

X7 

Customs  Information 

O 

1 

N/U 

080 

GOV 

Military  Standard  1840-A  Record  Definition 

O 

>1 

LOOPJO>SP1/REF 

9 

090 

REF 

Reference  Numbers 

O 

1 

10 

100 

DTM 

Date/Time  Reference 

O 

>1 

N/U 

110 

PER 

Administrative  Communications  Contact 

O 

>1 

LOOPJD-^SPimi 

Pi 

11 

120 

N1 

Name 

O 

1 

DC21  •  JULY  9  1993 


DEPARTMENT  OP  DEFENSE 

DRAFT  IMPLEMENTATION  CONVENTION 


ANSI  ASC  X12  VERIOSN/RELEASE  003030DOD 


16  010 


N/U  060 
N/U  065 
N/U  070 
N/U  074 
N/U  075 
N/U  076 
N/U  077 

N/U  078 
N/U  079 

N/U  080 
N/U  090 
N/U  100 

N/U  109 
N/U  110 
N/U  120 
N/U  130 


N2  Additional  Name  Information 

N3  Address  Information 

N4  Geographic  Location 

REF  Reference  Numbers 

PER  Administrative  Communications  Contact 


Table  2 


Marking,  Packaging,  Loading 

Measurements _ 

LOOPID'HL/RQ: 

Reference  Numbers 
Date/Time  Reference 
Administrative  Communications  Contact 
tOOPm-HULX  ^ 

Assigned  Number 
Measurements 
Oate/Time  Reference 
Reference  Numbers 

LOOPIO-Hl/ER 

Electronic  Format  Identification 
Military  Standard  1840-A  Record  Definition 

Binary  Data _ 

LOOPm-HUOD 
Characteristic/Class  ID 
Unit  Detail 
Test  Method 

Physical  Sample  Description 
Conditional  Sampling  Sequence 
Sampling  Parameters  for  Summary  Statistics 
Message  Text 


LOOPlID^Mt^lMillEA 

Measurements 


841  •  FURNISH 


SEG.ID 

NAME 

REa  OES. 

MAX  USE 

LOOP  REPEAT 

LOOMOvHL 

>i 

HL 

Hierarchical  Level 

M 

1 

LDOP-ID  s MUSPL  ;;  v 

>1 

SPI 

Specification  Idenofier 

o 

1 

RDT 

Revision  Date/Time 

o 

>1 

UN 

Item  Identification 

o 

1 

N1 

Name 

o 

>1 

MSG 

Message  Text 

o 

>1 

LOOPUl.HUf^O 

PID 

Product/ttem  Descnption 

o 

1 

PKD 

Packaging  Description 

o 

>1 

QTY 

Quantity 

o 

>1 

MEA 

Measurements 

o 

>1 

urr 

Unit  Detail 

o 

>1 

LOC 

Location 

o 

1 

PWK 

Paperwork 

0 

>1 
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N/U  240 
N/U  250 

N/U  260 
N/U  270 
N/U  280 

N/U  282 
N/U  283 

N/U  284 
N/U  285 
N/U  286 
N/U  287 

N/U  290 
N/U  300 
N/U  310 


PAGE*  POS.* 
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Date/Time  Reference 
Reference  Numbers 


Statistics 

Date/Time  Reference 
Reference  Numbers 


L<>OPU7-ML/aD/CSF 

Conditional  Sampling  Frequency 
Loop  Header 

Characteristic/Class  ID 
Measurements 

Statistics _ 

Loop  Trailer 


Electronic  Format  Identification 
Military  Standard  1840-A  Record  Definition 
Binary  Data 


Table  3 


SEaiD  NAME 


REaOES.  MAXUSE 


LOOP  REPEAT 


Transaction  Set  Trailer 


NOTES: 

2/010  To  be  meaningful,  at  least  one  of  the  SPI,  PID,  REF,  MEA,  EFI  or  CID  loops 
must  be  present  with  each  occurence  of  the  HL  loop. 

2/020  The  HL  segment  may  be  used  to  define  the  hierarchical  relationship  of  product-re¬ 
lated  specifications  reported  in  the  associated  HL  loop.  Product-related  specifica¬ 
tions  may  refer  to  the  product  in  its  entirety  or  to  subunits  of  the  product.  For 
example,  if  the  top  level  refers  to  an  assembly,  the  second-level  HL  segment 
may  refer  to  parts  or  subassemblies  of  the  top  assentfly.  This  pattern  may  be 
repeated  as  often  as  required. 

2/170  The  CID  segment  may  be  used  to  define  either  a  general  class  of  properties, 
such  as  physical  properties,  or  an  individual  property  within  a  class.  The  CID 
loop  allows  the  user  the  ability  to  define  specifications  such  as  the  properties  of 
the  item  or  class,  the  environmental  conditions  under  which  the  specifications 
apply,  the  test  methods  to  be  used,  and  other  parameters  related  to  properties 
within  the  current  HL  hierarchical  level. 

2/201  The  sanpling  sequence  specified  in  the  CSS  segment  will  take  precedence  over 
any  other  sampling  rate  (PSD03,  PSD09,  SPS06,  CSF02,  and  CSF03)  from  the 
point  the  CSS01  event  occurs  until  the  specified  sequence  is  completed. 

2/201  If  no  other  sampling  is  specified,  then  only  the  sampling  indicated  in  this  segment 
is  performed  when  the  CSS01  event  occurs. 

2/282  The  sampling  rate  specified  is  the  CSF  segment.  It  would  take  precedence  over 
the  normal  sampling  rate  specified  in  PSD03  while  the  conditions  of  the  CSF  seg¬ 
ment  are  satisfied,  but  would  NOT  take  precedence  over  the  sampling  sequence 
activated  by  the  proposed  CSS  segment. 
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2I2B2  It  no  Other  sampling  rate  is  specified,  then  the  only  sampling  indicated  in  the  CSF 
segment  is  performed  while  the  CSF  conditions  are  met.  Sampling  will  cease 
when  the  conditions  are  no  longer  met. 

2J282  Conditional  values  specified  in  DE  740  (Range  Minimum)  will  be  interpreted  as 
“greater  than  or  equal  to  this  value."  Values  specified  in  OE  741  (Range  Maxi¬ 
mum)  will  be  interpreted  to  mean  “less  than  or  equal  to  this  value.” 

2I2B2  Repetitions  of  the  CSF  loop  allow  several  frequency  changes  (and  the  conditions 
that  would  trigger  those  changes)  to  be  specified. 

2/2B2  If  the  conditions  are  such  that  several  CSF  values  are  activated  at  the  same 
time,  the  value  with  the  highest  sampling  rate  shall  prevail. 

2I2BA  Either  the  MEA  segment  or  the  ST  A  segment  must  occur,  but  not  both. 

2I2B4  The  CID  loop  within  the  CSF  loop  is  used  to  specify  the  conditions  that  will  trig¬ 
ger  activation  of  the  conditional  value  in  the  CSF  segment. 

2I2B4  Repetitions  of  the  CID  loop  will  have  an  implied  logical  AND  between  the  condi¬ 
tions  set  in  each  iteration. 

2I2BS  The  elements  of  the  CID  segment  identify  the  conditional  property.  If  the  property 
is  a  measurement  from  within  the  manufacturing  process  of  a  plant  environment, 
rather  than  the  product,  the  segment  also  identifies  the  location  where  the  meas¬ 
urements  are  to  be  observed. 

2J2B6  If  the  condition  is  based  on  single  test  measurements,  the  MEA  segment  is  used 
to  specify  the  units  of  measure,  and  the  open  or  closed  numeric  range  of  the  con¬ 
ditional  test. 
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Mandatory 


Mandatory 


Mandatory 


Segment:  ST  Transaction  Set  Header 
Level:  Header 

Loop:  _ 

Usage:  Mandatory 
Max  Use:  1 


Purpose:  To  indicate  the  start  of  a  transaction  set  and  to  assign  a  control  number 

Semantic:  The  transaction  set  identifier  (ST01 )  used  by  the  translation  routines  of 
the  interchange  partners  to  select  the  appropriate  transaction  set 
definition  (e.g.,  810  selects  the  invoice  transaction  set). 

_ Data  Element  Summary _ 

HMf.  DATA 

DBS. _ ILEMBWT  NAM€  ATmMUTBS 


ST01  143  Transaction  Set  Identifier  Code  M  ID  3/3 

Code  uniquely  identifying  a  Transaction  Set. 

841  XI  2.51  Spedfications/Technical  Information 

ST02  329  Transaction  Set  Conb’oi  Number  M  AN  4/9 

Identifying  control  number  that  must  be  unique  within  the  transaction  set 
functional  group  assigned  by  the  originator  for  a  transaction  set 

Implementation  Note: 

This  unique  number  is  assigned  by  the  originator  of  the  transaction  set  or  by  the  originator's  application 
program.  This  same  number  is  carried  in  SE02. 
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841  •  FURNISH 
SPI  •  SPECIFICATION  IDENTIRER 


Mandatory 


Segment:  SPI  Specification  Identifier 
Level:  Header 
Loop:  SPI  Repeat:  >1 
Usage:  Mandatory 
Max  Use:  1 

Purpose:  To  provide  a  description  of  the  included  specification  or  technical  data 
items. 


Mandatory 


_ Data  Element  Summary _ 

RIF.  DAT* 

OIS. _ IUmWT  KAMI _ ATTlMDUTtS _ 

SPI01  786  Security  Level  Code  M  ID  2/2 

Code  indicating  the  level  of  confidentiality  assigned  by  the  sender  to  the 
information  following. 

Implementation  Notes: 

1.  Use  any  code. 

2.  If  the  data  being  transmitted  have  both  a  government  security  classification  and  a  commercial  security 
protection  requirement,  then  this  data  element  will  carry  the  government  security  classification  code  and  the 
commercial  security  protection  code  will  be  carried  in  SPI09. 

3.  If  the  data  being  transmitted  have  only  one  prelection  requirement,  then  this  data  element  can  carry  either 
the  government  security  classification  code  or  the  commercial  security  protection  code. 

4.  Use  this  data  element  to  indicate  the  highest  protection  level  (government  or  commercial)  assigned  to  the 
data  being  provided.  Use  the  SPI  segment  at  the  Detail  level  to  indicate  the  protection  level  of  individual  data 
items. 


Mandatory 


Mandatory 


Not  Used 
Not  Used 
Not  Used 
Required 


SPI02  128  Reference  Number  Qualifier  M  ID  212 

Code  qualifying  the  Reference  Number. 

TN  Transaction  Reference  Number 
Code  Value  Implementation  Note: 

Use  Code  TN  for  the  unique  reference  number  of  this  transaction  set. 

SPI03  127  Reference  Number  M  AN  1/30 

Reference  number  or  identification  number  as  defined  for  a  particular 
Transaction  Set,  or  as  specified  by  the  Reference  Number  Qualifier. 

Implementation  Note: 

This  is  the  unique  reference  number  of  this  transaction  set. 


SPI04 

790 

Entity  Title 

0 

AN 

1/132 

SPI05 

791 

Entity  Purpose 

0 

AN 

1/80 

SPI06 

792 

Entity  Status  Code 

o 

ID 

1/1 

SPI07 

353 

Transaction  Set  Purpose  Code 

Code  identifying  purpose  of  transaction  set. 

0 

ID 

2/2 

Implementation  Note: 

Use  any  appropriate  listed  code. 

00  Original 
01  Cancellation 
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Optional 


Optional 


Not  Uaad 
Not  Uaad 
Not  Used 


Code  Value  Implementation  Note: 

Use  Code  01  when  cancelling  an  84 1  transaction  set  furnishing  specifications/ technical 
information.  When  Code  01  is  used,  only  the  HL  segment  {HU) I  and  HL03 )  at  the  Detail  level 
(Table  2)  is  needed. 

02  Add 
03  Delete 
04  Change 

SPI08  755  Report  Type  Code  O  ID  212 

Code  indicating  the  title  or  contents  of  a  document,  report  or  supporting  item 

Implementation  Note: 

Any  code  may  be  used,  although  the  following  codes  are  those  that  would  be  typically  used. 

AB  Assembly  Drawing 
DW  Drawing(s) 

ER  Engineering  Change  Request 

Code  Value  Implementation  Note: 

Use  Code  ER  to  indicate  technical  documentation  associated  with  an  Engineering  Change 
Proposal  (ECP). 

PA  Part  Drawing 
PF  Product  Specification 
Code  Value  Implementation  Note: 

Use  Code  PF  for  data  being  provided  in  support  of  a  proposal. 

SPIOO  786  Security  Level  Code  O  ID  212 

Code  indicating  the  level  of  confidentiality  assigned  by  the  sender  to  the 
information  following. 

Implementation  Notes: 

1.  Use  this  data  element  ONLY  when  SPIOi  is  Code  90,  92,  93,  94,  or  99,  and  the  data  being  provided  also 
have  a  commercial  security  protection  requirement. 

2.  Use  this  data  element  to  indicate  the  highest  level  of  commercial  security  protection  assigned  to  the  data 
being  transmitted.  Use  the  SPI  segment  at  the  Detail  level  to  indicate  the  commercial  security  protection  of 
individual  data  items. 

00  Company  Non-Classified 
01  Company  Internal  Use  Only 
02  Company  Confidential 

03  Company  Confidential,  Restricted  (Need  to  Know) 

04  Company  Registered  (Signature  Required) 

05  Personal 

09  Company  Defined  (Trading  Partner  Level) 


SPI10 

559 

Agency  Qualifier  Code 

O 

ID 

212 

SPI11 

916 

Code  List  Reference 

0 

AN 

1/6 

SPI12 

554 

Assigned  Number 

O 

NO 

1/6 
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NTE  ■  NOTE/SPECIAL  INSTRUCTION 


Optional 


Segment:  NTE  Note/Special  Instruction 
Level:  Header 
Loop:  SPI 
Usage:  Optional 
Max  Use:  >1 

Purpose:  To  transmit  information  in  a  free-form  format,  if  necessary,  tor  comment 
or  special  instruction 

Comment:  The  NTE  segment  permits  free-form  information/data  which,  under  ANSI 
X12  standard  implementations,  is  not  machine  processable.  The  use  of 
the  “NTE"  segment  should  therefore  be  avoided,  if  at  all  possible,  in  an 
automated  environment. 

ImplBtnentation  Note: 

Use  this  segment  to  provide  information  pertinent  to  the  entire  transaction  set.  To  provide 
information  relative  to  a  specific  data  item,  use  the  MSG  segment  in  Table  2. 


Optional 


Data  Element  Summa 


NTE01 


363  Note  Reference  Code  O  ID 

Code  identifying  the  functional  area  or  purpose  for  which  the  note  applies. 

GEN  Entire  Transaction  Set 
Code  Value  Implementation  Note: 

Use  Code  GEN  for  any  notes  that  relate  to  the  entire  transaction  set. 


Mandatory 


NTE02 


Free  Form  Message 

Free-form  text. 


M  AN  1/60 
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Optional 


Segment:  REF  Reference  Numbers 
Level:  Header 

Loop:  SPI/REF  Repeat:  >1 
Usage:  Optional 
Max  Use:  1 

Purpose:  To  specify  identifying  numbers. 

Syntax:  R0203  —  At  least  one  of  REF02  or  REF03  is  required. 
Implementation  Note: 

Use  the  REF  segment  to  provide  reference  numbers  applicable  to  the  data  being  provided.  For 
example,  provide  the  Engineering  Change  Proposal  number  and  effected  con: 'act  number!  s)  if  the 
data  pertain  to  an  EC P;  or  provide  the  quote  number  and  applicable  solicitation  number  if  the  ditto 
is  related  to  a  proposal  -n  response  to  an  RFQ. 


Mandatory 


Conditional 


Not  Usod 


_ Data  Element  Summary _ 

Air  DATA  _ 

OIS.  ELIMIKT  MAm  _ ATmiAUTKS 

REF01  128  Reference  Number  Qualifier  M  ID  2/2 

Code  qualifying  the  Reference  Number. 

39  Proposal  Number 
Code  Value  Implementation  Note: 

Use  Code  39  for  an  Engineering  Change  Proposal  number  to  which  the  data  in  this  transaction  set 
pertain. 

C4  Change  Number 
Code  Value  Implementation  Note: 

Use  Code  C4  for  the  contract  modification  number  to  which  the  data  in  this  transaction  set  pertain. 

CT  Contract  Number 
Code  Value  Implementation  Note: 

Use  Code  CT  to  specify  the  contract  to  which  the  data  in  this  transaction  set  pertain. 

KS  Solicitation 

Code  Value  Implementation  Note: 

Use  Code  KSfor  the  solicitetliem  number  to  which  the  detta  in  this  transaction  set  pertain. 

Q1  Quote  Number 
Code  Value  Implementation  Note: 

Use  Code  Ql  for  the  quote  number  to  which  the  data  in  this  transaction  set  pertain. 

TN  Transaction  Reference  Number 
Code  Value  Implementation  Note: 

Use  Code  TN  for  the  unique  reference  number  of  this  transaction  set. 

ZZ  Mutually  Defined 
Code  Value  Implementation  Note: 

If  applicable,  use  Code  ZZ  for  the  unique  reference  number  of  the  trans  action  set  to  which  the  data 
in  this  transaction  set  pertain. 

REF02  127  Reference  Number  C  AN  1/30 

Reference  number  or  identification  number  as  defined  for  a  particular 
I  ransaction  Set,  or  as  specified  by  the  Reference  Number  Qualifier. 

REF03  352  Description  C  AN  1/80 
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DTM  •  OATETIME  REFERENCE 


Optional 


Segment:  DTM  Date/Time  Reference 
Level:  Header 
Loop:  SPI/HEF 
Usage:  Optional 
Max  Use:  >1 

Purpose:  To  specify  pertinent  dates  and  times 
Syntax:  R0203  —  At  least  one  of  DTM02  or  DTM03  is  required. 


Mandatory 


Conditional 

Not  Used 
Not  Used 
Not  Used 


_ Data  Element  Summary _ 

REP  DATA 

OES.  ELEMEKT  NAEtf  ATTmEOTES 

DTM01  374  Oata/Time  Qualifier  M  ID  3/3 

Code  specifying  type  of  date  or  time,  or  bcth  date  and  time. 

092  Contract  Effective 
Code  Value  Implementation  Note: 

When  REFOI  is  Code  CT,  use(.iode  092  to  indicate  the  date  of  the  contract  specified  in  REF02. 

097  Transaction  Creation 
Code  Value  Implementation  Note: 

When  REFOI  is  Code  TN,  use  Code  097  to  indicate  the  creation  date  of  this  transaction  set. 

■'98  Bid  (Effective) 

Code  Value  Implementation  Note: 

When  REFOI  is  Code  QI ,  use  Code  09S  to  indicate  the  date  of  the  quote  specified  in  REF02 . 

152  Effective  Date  of  Change 
Code  Value  Implementation  Note: 

When  REFOI  is  Code  C4,  use  Code  152  to  indicate  the  effective  date  of  the  modification. 

368  Submittal 

Code  Value  Implementation  Note: 

When  REFOI  is  Code  ZZ.  use  Code  368  to  ind'cate  th.  date  of  the  referenced  transact'on  set 
specified  in  REF02. 

993  Request  for  Quotation 
Code  Value  Implementation  Note: 

When  REFOI  is  Code  KS,  use  Code  993  to  indicate  the  date  of  the  solicitation  specified  in  REF02. 

ZZZ  Mutually  Defined 
Code  Value  Implementation  Note: 

When  REFOI  is  Code  39,  use  Code 722.  for  the  date  of  the  Engineering  Change  Proj  •’/. 


DTM02 

373 

Date 

Date  (YYMMDD). 

C 

DT 

6/6 

DTM03 

337 

Time 

C 

TM 

4>d 

DTM04 

623 

Time  Code 

0 

ID 

2/2 

DTM05 

624 

Century 

O 

NO 

2/2 
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Optional 


Mandatory 


Conditional 


Conditional 


Conditional 


Segment:  N1  Name 
Level:  Header 


.1 


Loop:  SPI/N1  Repeat: 

Usage:  Optional 
Max  Use:  1 

Purpose:  To  identify  a  party  by  type  of  organization,  name  and  code 

Syntax:  1.  R0203  —  At  least  one  of  N102  or  N103  is  required. 

2.  P0304  —  If  either  N1 03  or  N104  is  present,  then  the  other  is  required. 

Comment:  This  segment,  used  alone,  provides  the  most  efficient  method  of 

providing  organizational  identification.  To  obtain  this  efficiency  the  "ID 
Code"  (N104)  must  provide  a  key  to  the  table  maintained  by  the 
transaction  orocessing  party. 

Implementation  Note: 

Whenever  possible,  idenlificaiion  and  address  information  should  be  provided  using  N 101,  N103, 
and  N104.  Use  N102  and  segmerus  N2  through  N4  when  this  information  cannot  be  provided  by 
use  of  a  CAGE  code  or  a  DoDAAC. 

_ Data  Element  Summary _ 


REF. 

DtS. 


N101 


DATA 

ILBICMT  NAME 


98  Entity  Identifier  Code  M  ID  2/2 

Code  identifying  an  organizational  entKy,  a  physical  location,  or  an  individual 

BY  Buying  Party  (Purchaser) 

FR  Message  From 
SE  Selling  Party 
TO  Message  To 


N102 


N103 


93  Name 

Free-form  name. 


C  AN  1/35 


66  Identification  Code  Qualifier  C  10  1/2 

Code  designating  the  system/method  of  code  structure  used  for  Identification 
Code  (67). 

10  Department  of  Defense  Activity  Address  Code  (DODAAC) 

33  Commercial  and  Government  Entity  (CAGE) 


N104 


67  Identification  Code 

Code  identifying  a  party  or  other  code. 


C  AN  2/17 
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841  •  FURNISH 
N2  •  ADDITIONAL  NAME  INFORMATION 


Optional 


Segment:  N2  Additional  Name  information 
Level:  Header 
Loop:  SPI/N1 
Usage:  Optional 
Max  Use:  2 

Purpose:  To  specify  additional  names  or  those  longer  than  35  characters  in  length 
Implementation  Note: 

This  segment  is  not  necessary  when  the  entity  cited  in  N 101  is  described  by  use  of  a  CAGE  code  or 
a  DoDAAC. 


Mandatory 


Optional 


Data  Element  Summary 


MtP. 

OCS. 

DATA 

ELfHOn 

NAME 

ATmtBtnES 

N201 

93 

Name 

Free-form  name. 

M 

AN 

1/35 

N202 

93 

Name 

Free-form  name. 

O 

AN 

1/35 
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DEPARTMENT  OF  DEFENSE 
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841  *  FURNISH 

N3  •  ADDRESS  INFORMATION  ANSI  ASC  X12  VERIOSN/RELEASE  003030DOD 


Optional 


Segment:  N3  Address  Information 
Level:  Header 
Loop:  SPI/N1 
Usage:  Optional 
Max  Use:  2 


Purpose:  To  specify  the  location  of  the  named  party 

Implementation  Note: 

This  segmeru  is  not  necessary  when  the  entity  cited  in  NlOl  is  described  by  use  of  a  CAGE  code  or 
a  DoDAAC. 


Mandatory 


Optional 


Data  Element  Summary 


DATA 

fLEMCKT 

MAMC 

ATTintirrts 

N301 

166 

Address  Information 

Address  information 

M 

AN 

1/35 

N302 

166 

Address  Information 

Address  information 

0 

AN 

1/35 
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641  •  FURNISH 
N4  •  GEOGRAPHIC  LOCATION 


Optional 


Segment:  N4  Geographic  Location 
Levei:  Header 
Loop:  SPI/N1 
Usage:  Optional 
Max  Use:  1 


Purpose:  To  specify  the  geographic  place  of  the  named  party 

Syntax:  1.  R01 05  —  At  least  one  of  N401  or  N405  is  required. 

2.  P0506  —  If  either  N405  or  N406  is  present,  then  the  other  is  required. 

Comments:  1.  A  combination  of  either  N401  through  N404  (or  N405  and  N406)  may 
be  adequate  to  specify  a  location. 

2.  N402  is  required  only  if  city  name  (N401 )  is  in  the  USA  or  Canada. 

Implementation  Note: 

This  segment  is  not  necessary  when  the  entity  cited  in  NIOI  is  described  by  use  of  a  CAGE  code  or 
a  DoDAAC. 


Conditional 

Optional 

Optional 

Optional 

Conditional 

Conditional 


Data  Element  Summary 


^1 

DATA 

CLOftCKT 

NAME 

ATTfMAvrBS 

N401 

19 

City  Name 

Free-form  text  for  city  name. 

C 

AN  2/30 

N402 

156 

State  or  Province  Code  0  ID  2/2 

Code  (Standard  State/Province)  as  defined  by  appropriate  government  agency. 

N403 

116 

Postal  Code  O  ID  3/9 

Code  defining  international  postal  zone  code  excluding  punctuation  and  blanks 
(zip  code  for  United  States). 

N404 

26 

Country  Code 

Code  identifying  the  country. 

O 

ID  2/3 

N405 

309 

Location  Qualifier 

Code  identifying  type  of  location. 

c 

ID  1/2 

N406 

310 

Location  Identifier 

Code  vrhich  identifies  a  specific  location. 

c 

AN  1/25 

DC21  -JULYSISSS 
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PER  •  ADMINSTRATIVE  COMMUNICATIONS  CONTACT  ANSI  ASC  Xl2  VERIOSN/RELEASE  00303000D 


Segment:  PER  Administrative  Communications  Contact 
Level:  Header 


Optioral 


Loop:  SPI/N1 
Usage:  Optional 
Max  Use:  >1 


Purpose:  To  identify  a  person  or  office  to  whom  administrative  communications 
should  be  directed 

Syntax:  1.  P0304  —  If  either  PER03  or  PER04  is  present,  then  the  other  is 
required. 

2.  P0506  —  If  either  PER05  or  PER06  is  present,  then  the  other  Is 
required. 


Mandatory 


Optional 


Conditional 


Conditional 


Conditional 


Conditional 


_ Data  Element  Summary _ 

nr.  DATA 

PIS. _ ILimMt  KAMA _ ATTIMPUTP 

PER01  366  Contact  Function  Code  M  ID  2/2 

Code  identifying  the  major  duty  or  responsibility  of  the  person  or  group  named. 

1C  Information  Contact 
Code  Value  Implementation  Note: 

Use  Code  1C  for  the  irformation  point  of  contact  within  the  originator' s  organization. 

PER02  93  Name  O  AN  1/35 

Free-form  name. 

Implementation  Note; 

Use  to  provide  the  name  of  the  irformation  point  of  contact. 

PER03  365  Communication  Number  Quaiifier  C  ID  2/2 

Code  identifying  the  type  of  communication  number. 

Implementation  Note: 

Use  any  appropriate  listed  code,  although  Code  EM  is  prferred. 

EM  Electronic  Mail 
FX  Facsimile 
TE  Telephone 
TM  Telemail 

PER04  364  Communication  Number  C  AN  1/25 

Complete  communications  number  including  country  or  area  code  when 
applicable. 

PER05  365  Communication  Number  Qualifier  C  ID  2/2 

Code  identifying  the  type  of  communication  number. 

PER06  364  Communication  Number  C  AN  1/25 

Complete  communications  number  including  country  or  area  code  when 
applicable. 
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841  •  FURNISH 
HL  •  HIERARCHICAL  LEVEL 


Mandatory 


Segment;  HL  Hierarchical  Level 
Level:  Detail 


Loop:  HL  Repeat:  >1 
Usage:  Mandatory 
Max  Use:  1 


Purpose:  To  identify  dependencies  among  and  the  content  of  hierarchically  related 
groups  of  data  segments. 

Comments:  1.  The  HL  Segment  is  used  to  identify  levels  of  detail  information  using  a 
Hierarchical  Structure,  such  as  relating  line  item  data  to  shipment  data, 
and  packaging  data  to  line  item  data. 

2.  The  HL  segment  defines  a  top-down/left-right  ordered  structure. 

3.  HL01  shall  contain  a  unique  alphanumeric  number  for  each 
occurrence  of  the  HL  segment  in  the  transaction  set.  For  example  HL01 
could  be  used  to  indicate  the  number  of  occurrences  of  the  HL  segment, 
in  which  case  the  value  of  HL01  would  be  ”1"  for  the  initial  HL  segment, 
and  would  be  incremented  by  one  in  each  subsequent  HL  segment 
within  the  transaction. 


4.  HL02  identifies  the  Hierarchical  ID  Number  of  the  HL  segment  to 
which  the  current  HL  segment  is  subordinate. 

5.  HL03  indicates  the  context  of  the  series  of  segments  following  the 
current  HL  segment  up  to  the  next  occurrence  of  an  HL  segment  in  the 
transaction.  For  example,  HL03  is  used  to  indicate  that  subsequent 
segments  in  the  HL  loop  form  a  logical  grouping  of  data  referring  to 
shipment,  order  or  item  level  information. 

6.  HL04  indicates  whether  or  not  there  are  subordinate  (or  child)  HL 
segments  related  to  the  current  HL  segment. 


Implementation  Notes: 

I.  The  HL  loop  can  be  used  to  transmit  a  single  item  of  technical  information  or  multiple  items  that 
may  or  may  not  have  a  hierarchical  relationship. 


2.  When  providing  a  single  item  of  technical  information,  only  one  iteration  of  the  HL  loop  is 
necessary. 


3.  When  transmitting  multiple  items  that  may  or  may  not  have  a  hierarchical  relationship,  repeat 
the  HL  loop  as  many  times  as  required  to  specify  all  levels  and  use  as  many  iterations  of  the 
HL/SPI  loop  as  necessary. 


4.  When  SPI07  is  Code  01 ,  the  only  entries  in  the  Detail  level  {Table  2 )  are  in  HLOl  and  HL03 . 


Mandatory 


_ Data  Element  Summary _ 

REP.  DATA 

PES. _ ELEMEWT  NAME  _ ATTWEUTES 

HLOl  628  Hierarchical  ID  Number  M  AN  1/12 

A  unique  number  assigned  by  the  sender  to  identify  a  particular  data  segment  in 
a  hierarchical  structure. 
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HL  •  HIERARCHICAL  LEVEL 


ANSI  ASC  X12  VERIOSN/RELEASE  003030DOD 


Optional 


Mandatory 


Implenwntation  Note: 

This  is  a  unique  and  progressive  number  assigned  by  the  originator  of  the  transaction  set  starling  with  the 
number  1. 

HL02  734  Hierarchical  Parent  ID  Number  O  AN  1/12 

Identification  number  of  the  next  higher  hierarchical  data  segment  that  the  data 
segment  being  described  is  subordinate  to. 

Implementation  Note: 

This  data  element  is  used  only  when  providing  multiple  items  of  technical  information  that  have  a 
hierarchical  relationship. 

HL03  735  Hierarchical  Level  Code  M  ID  1/2 

Code  defining  the  characteristic  of  a  level  in  a  hierarchical  structure. 

Implementation  Note: 

Use  any  appropriate  listed  code  to  indicate  the  hierarchical  relationship  of  the  data  provided. 

A  Assembly 
F  Component 
I  Item 

Code  Value  Implementation  Note: 

Use  Code  I  as  the  default  code  when  no  other  code  is  applicable. 

SY  System 
U  Subassembly 
ZZ  Mutually  Defined 

Code  Value  Implementation  Note: 

Use  Code  2Z  only  when  SP'('7  is  Code  01.  This  is  required  to  comply  with  the  mandatory  nature  of 
the  data  element. 


Optional 


HL04  736  Hierarchical  Child  Code  O  ID  1/1 

Code  indicating  whether  if  there  are  hierarchical  child  data  segments  subordinate 
to  the  level  being  described. 

Implementation  Note: 

When  providing  single  or  multiple  specifications/technical  information  that  have  no  hierarchical  structure, 
no  entry  is  required. 

0  No  Subordinate  HL  Segment  in  This  Hierarchical  Structure. 

Code  Value  Implementation  Note: 

Use  Code  0  to  indicate  the  lowest  level  in  the  hierarchical  relationship. 

1  Additional  Subordinate  HL  Data  Segment  in  This  Hierarchical  Structure. 

Code  Value  Implementation  Note: 

Use  Code  I  to  indicate  there  are  lower  level  items  in  this  hierarchical  relationship. 
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ANSI  ASC  X12  VERIOSN/RELEASE  003030DOD_  SPI  •  SPECIFICATION  IDENTIFIER 


Optional 


Segment:  SPI  Specification  identifier 
Level:  Detail 

Loop:  HUSPI  Repeat:  >1 
Usage:  Optional 
Max  Use:  1 

Purpose:  To  provide  a  description  of  the  included  specification  or  technical  data 
items. 


Mandatory 


Mandatory 


Mandatory 


_ Data  Element  Summary _ 

dIs! _ tLBWPIT  tout _ ATTWUTtS 

SPI01  786  Security  Level  Code  M  ID  2/2 

Code  indicating  the  level  of  confidentiality  assigned  by  the  sender  to  the 
information  following. 

Implementation  Notes: 

1.  Use  any  code. 

2.  If  the  data  item  being  transmitted  has  both  a  government  security  classification  and  a  commercial  security 
protection  requirement,  then  this  data  element  will  carry  the  government  security  classification  code  and  the 
commercial  security  protection  code  will  be  carried  in  SPI09. 

3.  If  the  data  item  being  transmitted  has  only  one  protection  requirement,  then  this  data  element  can  carry 
either  the  governmeru  security  classification  or  the  commercial  security  protection  code. 


SPI02  128  Reference  Number  Qualifier  M  10  2/2 

Code  qualifying  the  Reference  Number. 

Implementation  Note: 

Any  code  may  be  used  but  typically  used  codes  include: 

DD  Document  Identification  Code 
Code  Value  Implementation  Note: 

Use  Code  DD  for  the  reference  number  of  an  Engineering  Data  List. 

DG  Drawing  Number 

QC  Product  Specification  Document  Number 

51  Engineering  Specification  Number 

52  Military  Specification  Number  (MILSPEC) 

53  Specification  Number 

TP  Test  Specification  Number 
W9  Special  Packaging  Instruction  Number 
ZZ  Mutually  Defined 
Code  Value  Implementation  Note: 

Use  Code  ZZ  for  another  type  of  reference  number  and  identify  that  number  in  SPI04. 


SPI03  127  Reference  Number  M  AN  1/30 

Reference  number  or  identification  number  as  defined  for  a  particular 
Transaction  Set,  or  as  specified  by  the  Reference  Number  Qualifier. 


Optional 


SPI04 


790  Entity  Title 

Title  of  the  data  entity. 


O  AN  1/132 
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SPI  •  SPECIRCATION  IDENTIFIER  ANSI  ASC  X12  VERIOSN/RELEASE  003030DOD 


NolUMd 

Optional 


Not  Used 
Not  Used 
Optional 


Not  Uaod 
Not  Uaad 
Not  Used 


Implementation  Note: 

When  SPI02  is  Code  ZZ,  identify  the  reference  number  cited  in  SPI03. 

SPI05  791  Entity  Purpose  O  AN  1/80 

SPI06  792  Entity  Status  Code  O  ID  1/1 

Code  indicating  the  current  status  of  the  data  item  specified  by  the  electronic 
data  item. 

Implementation  Note: 

Use  any  code. 

Z  Mutually  Defined 

Code  Value  Implementation  Note: 

Use  Code  Z  for  another  entity  status  condition  and  explain  in  the  MSG  segmeru. 


SPI07 

353 

Transaction  Set  Purpose  Code 

O 

ID 

2/2 

SPI08 

755 

Report  Type  Code 

O 

ID 

2/2 

SPI09 

786 

Security  Level  Code 

0 

ID 

2/2 

Code  indicating  the  level  of  confidentiality  assigned  by  the  sender  to  the 
information  following. 


Implementation  Note: 

Use  this  data  element  ONLY  when  SPIOI  is  Code  90,  92,  93,  94,  or  99  and  the  data  item  being  transmitted 
also  has  a  commercial  security  protection  requirement. 

00  Company  Non-Classified 
01  Company  Internal  Use  Only 
02  Company  Confidential 

03  Company  Confidential,  Restricted  (Need  to  Know) 

04  Company  Registered  (Signature  Required) 

05  Pv<rrsonal 

09  Company  Defined  (Trading  Partner  Level) 


SPI10 

559 

Agency  Qualifier  Code 

0 

ID 

2/2 

SPI11 

916 

Code  List  Reference 

O 

AN 

1/6 

SPI12 

554 

Assigned  Number 

O 

NO 

1/6 
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841  •  FURNISH 
RDT  •  REVISION  DATEHMIE 


Optional 


Segment:  RDT  Revision  Date/Time 
Level:  Detail 


Loop:  HLySPI 
Usage:  Optional 
Max  Use:  >1 

Purpose:  To  specify  the  revision  level  of  the  electronic  data  item. 

Syntax:  1.  C01 02  —  If  RDT01  is  present,  then  RDT02  is  required. 

2.  L030405  —  If  RDT03  is  present,  then  at  least  one  of  RDT04  or 
RDT05  are  required. 

3.  C0605  —  If  RDT06  is  present,  then  RDT05  is  required. 


Implementation  Note: 

Use  this  segment  to  specify  the  change  and/or  revision  to  the  specification/ technical  information 
being  provided. 


Optional 


Conditional 


_ Data  Element  Summary _ 

RCF.  DATA 

DP. _ ILIMIKT  MAMt _ ATI— UTP 

RDT01  795  Revision  Level  Code  O  ID  1/1 

Code  indicating  the  revision  or  engineering  change  level  of  the  data  items 
referred  to  by  the  specification  number. 

A  Change  Level 
E  Revision  Level 
H  Version  Level 

RDT02  796  Revision  Value  C  AN  1/30 

Revision  or  engineering  change  level  of  the  data  items  referred  to  by  the 
specification  number. 

Implementation  Notes: 

1.  When  RDTOI  is  Code  A  or  Code  E,  insert  the  change  or  revision  number/ letter. 

2,  When  RDTOI  is  Code  H,  specify  the  version  being  transmitted,  e.g.,  "As-Built"  or  "As-Shipped". 


Optional 


RDT03  374  Date/Time  Qualifier  O  ID  3/3 

Code  specifying  type  of  date  or  time,  or  both  date  and  time. 

007  Effective 

Code  Value  Implementation  Note: 

Use  Code  007  to  specify  the  change,  revision,  or  version  date. 


Conditional 


RDT04  373  Date  C  DT  6/6 

Date  (YYMMDD). 

Implementation  Note: 

Enter  the  date  of  the  change,  revision,  or  version  being  transmitted  in  this  transaction  set. 


Not  Used 
Not  Used 


RDT05 

337 

Time 

RDT06 

623 

Time  Code 

C  TM  4/6 
O  ID  2/2 
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Segment:  LIN  Item  Idemification 
Level:  Detail 
Loop:  HL/SPI 
Optional  Usage:  Optional 

Max  Use:  1 

Purpose:  To  specify  basic  item  identification  data. 

Syntax:  1.  C0405  —  If  LIN04  is  present,  then  LINOS  is  required. 

2.  C0607  —  If  LIN06  is  present,  then  LIN07  is  required. 

3.  C0809  —  If  LINOS  is  present,  then  LtN09  is  required. 

4.  C101 1  —  If  LIN10  is  present,  then  LIN1 1  is  required. 

5.  C1213  —  If  LIN12  is  present,  then  LIN13  is  required. 

6.  C1415  —  If  LIN14  is  present,  then  LIN15  is  required. 

7.  C1617  —  If  LIN16  is  present,  then  LIN17  is  required. 

8.  C1819  —  If  LIN18  is  present,  then  LIN19  is  required. 

9.  C2021  —  If  LIN20  is  present,  then  LIN21  is  required. 

10.  C2223  —  If  LIN22  is  present,  then  LIN23  is  required. 

11.  C2425  —  If  LIN24  is  present,  then  LIN25  is  required. 

12.  C2627  —  If  LIN26  is  present,  then  LIN27  is  required. 

13.  C2829  —  If  LIN28  is  present,  then  LIN29  is  required. 

14.  C3031  —  If  LIN30  is  present,  then  LIN31  is  required. 

Semantic:  LIN01  is  the  line  item  identification 

Comments:  1.  See  the  Data  Dictionary  for  a  complete  list  of  ID’S. 

2.  LIN02  through  LiN31  provide  for  fifteen  (15)  different  product/service 
ID’S  for  each  item.  For  Sample:  Case,  Color,  Drawing  No.,  UPC  No., 
ISBN  No..  Model  No.,  SKU. 

Implementation  Notes: 

1.  Use  this  segment  to  transmit  information  relative  to  the  data  item  identified  in  SPI03. 

2.  LIN02  through  LIN3 1  are  used  in  pairs  {e.g.,  LINOZ  and  LIN03 )  as  required  to  carry  additional 
information  about  the  specific  data  item  identified  in  SPI03. 

_  Data  Element  Summa 


Not  Used  LIN01  350  Assigned  Identification  O  AN 

Mandatory  LIN02  235  Product/Service  ID  Qualifier  M  ID 

Code  identifying  the  type/source  of  the  descriptive  number  used  in 
Product/Service  ID  (234). 

F7  End-Item  Description 

Code  Value  Implementation  Note: 

Use  Code  F7  for  the  application  r^erence. 
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UN  •  ITEM  IDENTIFICATION 


Mandatory 

Optional 

Conditional 

Optional 

Conditional 

Optional 

Conditional 

Optional 

Conditional 

Optional 

Conditional 

Optional 


LIN03 

LIN04 

LINOS 

LINOS 

LIN07 

LINOS 

LIN09 

LIN10 

LIN11 

LIN12 

LIN13 

LIN14 


FS  National  Stock  Number 

Code  Value  knplementation  Note: 

Use  Code  FS  for  the  National  Slock  Number. 

IN  Buyer's  Item  Number 
Code  Value  Implementation  Note: 

Use  Code  IN  for  the  CUN  or  SUBCUN 

MG  Manufacturer's  Part  Number 

Code  Value  Implementation  Note: 

Use  Code  MG  for  the  manufacturer's  pan  number. 

PD  Part  Number  Description 

Code  Value  Implementation  Note: 

Use  Code  PD  to  provide  a  noun  description  of  the  item  to  which  the  data  item  identified  in  SPIOJ 
pertains. 

234  Product/Service  10  M  AN  1/30 

Identifying  number  for  a  product  or  service. 

235  Product/Service  ID  Qualifier  O  ID  2/2 

Code  identifying  the  type/source  of  the  descriptive  number  used  in 
Product/Service  ID  (234). 

234  Product/Service  ID  C  AN  1/30 

Identifying  number  for  a  product  or  service. 

235  Product/Service  ID  Qualifier  O  ID  2/2 

Code  identifying  the  type/source  of  the  descriptive  number  used  in 
Product/Service  ID  (234). 

234  Product/Service  ID  C  AN  1/30 

Identifying  number  for  a  product  or  service. 

235  Product/Service  ID  Qualifier  O  ID  2/2 

Code  identifying  the  type/source  of  the  descriptive  number  used  in 
Product/Service  ID  (^4). 

234  Product/Service  ID  C  AN  1/30 

Identifying  number  for  a  product  or  service. 

235  Product/Service  ID  Qualifier  O  ID  2/2 

Code  identifying  the  type/source  of  the  descriptive  number  used  in 
Product/Service  ID  (234). 

234  Product/Service  ID  C  AN  1/30 

Identifying  number  for  a  product  or  service. 

235  Product/Service  ID  Qualifier  O  ID  2/2 

Code  identifying  the  type/source  of  the  descriptive  number  used  in 
Product/Service  ID  (234). 

234  Product/Service  ID  C  AN  1/30 

Identifying  number  for  a  product  or  service. 

235  Product/Service  ID  Qualifier  O  ID  2/2 

Code  identifying  the  type/source  of  the  descriptive  number  used  in 
Product/Service  ID  (234). 
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Conditional 

UNIS 

234 

Product/S«rvic«  ID  C 

Identifying  number  for  a  product  or  service. 

AN 

1/30 

Optional 

LIN16 

235 

Product/Service  ID  Qualifier  O 

Code  identifying  the  type/source  of  the  descriptive  number  used  in 
Product/Service  ID  (234). 

ID 

2/2 

Conditional 

LIN17 

234 

Product/Sarvice  iO  C 

Identifying  number  for  a  product  or  service. 

AN 

1/30 

Optional 

LIN18 

235 

Product/Service  ID  Qualifier  O 

Code  identifying  the  type/source  of  the  descriptive  number  used  in 
Product/Service  ID  (234). 

ID 

2/2 

Conditional 

LIN19 

234 

Product/Service  ID  C 

Identifying  number  for  a  product  or  service. 

AN 

1/30 

Optional 

LIN20 

235 

Product/Service  ID  Qualifier  O 

Code  identifying  the  type/source  of  the  descriptive  number  used  in 
Product/Service  ID  (234). 

ID 

2/2 

Conditional 

LIN21 

234 

Product/Service  ID  C 

Identifying  number  for  a  product  or  service. 

AN 

1/30 

Optional 

LIN22 

235 

Product/Service  ID  Qualifier  0 

Code  identifying  the  type/source  of  the  descriptive  number  used  in 
Product/Service  ID  {J^4). 

ID 

2/2 

Conditional 

LIN23 

234 

Product/Service  ID  C 

Identifying  number  for  a  product  or  service. 

AN 

1/30 

Optional 

LIN24 

235 

Product/Service  ID  Qualifier  0 

Code  identifying  the  type/source  of  the  descriptive  number  used  in 
Product/Service  ID  (^4). 

ID 

2/2 

Conditional 

LIN2S 

234 

Product/Service  ID  C 

Identifying  number  for  a  product  or  service. 

AN 

1/30 

Optional 

LIN26 

235 

Product/Service  ID  Qualifier  0 

Code  identifying  the  type/source  of  the  descriptive  number  used  in 
Product/Service  ID  (^4). 

ID 

2/2 

Conditional 

LIN27 

234 

Product/Service  ID  C 

Identifying  number  for  a  product  or  service. 

AN 

1/30 

Optional 

LtN28 

235 

Product/Service  ID  Qualifier  0 

Code  identifying  the  type/source  of  the  descriptive  number  used  in 
Product/Service  ID  (234). 

ID 

2/2 

Conditional 

LIN29 

234 

Product/Service  ID  C 

Identifying  number  for  a  product  or  service. 

AN 

1/30 

Optional 

LIN30 

235 

Product/Service  ID  Qualifier  O 

Code  identifying  the  type/source  of  the  descriptive  number  used  in 
Product/Service  ID  (234). 

ID 

2/2 

Conditional 

LIN31 

234 

Product/Service  ID  C 

AN 

1/30 

23 
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N1  •  NAME 


ANSI  ASC  X12  VERIOSN/RELEASE  00303000D_ 


Optional 


Segment:  N1  Name 
Level:  Detail 
Loop:  HL/SPl 
Usage:  Optional 
Max  Use:  >1 

Purpose:  To  identify  a  party  by  type  of  organization,  name  and  code 

Syntax:  1.  R0203  —  At  least  one  of  N1 02  or  N1 03  is  required. 

2.  P0304  —  If  either  N103  or  N104  is  present,  then  the  other  is  required. 

Comment:  This  segment,  used  alone,  provides  the  most  efficient  method  of 

providing  organizational  identification.  To  obtain  this  efficiency  the  "ID 
Code"  (N1 04)  must  provide  a  key  to  the  table  maintained  by  the 
transaction  processing  party. 


Mandatory 


Conditional 


Conditional 


Conditional 


_ Data  Element  Summary _ 

REF.  DATA 

DES.  ELEMEKT  NAME _ ATHtMUTES 

N101  98  Entity  Identifier  Code  M  ID  212 

Code  identifying  an  organizational  entity,  a  physical  location,  or  an  individual 

ZE  End  Item  Manufacturer 

Code  Value  Implementation  Note: 

Use  Code  ZE  to  identify  the  manufacturer  of  an  item. 


N102 

93 

Name 

Free-form  name. 

C 

AN 

1/35 

N103 

66 

Identification  Code  Qualifier 

C 

ID 

1/2 

Code  designating  the  system/method  of  code  structure  used  for  Identification 
Code  (67). 


N104  67  Identification  Code  C  AN  2/17 

Code  identifying  a  party  or  other  code. 
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ANSI  ASC  X12  VERIOSN/RELEASE  003030DOD_ _ MSG  •  MESSAGE  TEXT 

Segment:  MSG  Message  Text 
Level:  Detail 
Loop:  HUSPI 
Optional  Usage:  Optional 

Max  Use:  >1 

Purpose:  To  provide  a  free  form  format  that  would  allow  the  transmission  of  text 
information. 

Comment:  MSG02  is  not  related  to  the  specific  characteristics  of  a  printer,  but 
identifies  top  of  page,  advance  a  line,  etc. 

Implementation  Notes: 

1.  Use  this  data  segment  to  transmit  information  relative  to  a  specific  data  item. 

2.  Maximum  use  is  3. 


Data  Element  Summai 


MF. 

DCS. 

DATA 

ELEMENT 

NAME 

ATTfMirTES 

Mandatory 

MSG01 

933 

Free-Form  Message  Text 

Free-form  message  text. 

M 

AN 

1/264 

Not  Uaod 

MSG02 

934 

Printer  Carriage  Control  Code 

0 

ID 

2/2 
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Optional 


Segment:  EFI  Electronic  Format  identification 
Level:  Detail 

Loop:  HL/EFI  Repeat:  >1 
Usage:  Optional 
Max  Use:  1 

Purpose:  To  provide  basic  information  about  the  electronic  format  of  the 
interchange  data. 

Syntax:  1.  C0504  —  If  EFI05  is  present,  then  EFI04  is  required. 

2.  C0706  —  If  EFI07  is  present,  then  EFI06  is  required. 

3.  C0908  —  If  EFI09  is  present,  then  EFI08  is  required. 

Implementation  Note: 

Maximum  use  is  I  for  each  HL. 


Mandatory 


Optioital 


EFI01  786  Security  Level  Code  M  ID  2/2 

Code  indicating  the  level  of  confidentiality  assigned  by  the  sender  to  the 
information  following. 

Implementation  Notes: 

].  Use  any  appri^riate  code. 

2.  The  security  level  code  specified  here  relates  to  the  specific  binary  data  provided  in  the  BIN  segment. 

3.  The  security  code  provided  for  the  binary  data  being  transmitted  in  the  BIN  segmeru  is  the  highest 
protection  level  assigned  to  the  data.  If  the  data  have  both  a  government  security  classification  and  a 
commercial  security  protection  requirement,  the  government  security  classification  lakes  precedence  and 
shall  be  provided  in  this  data  element. 


EFi02  933  Free>Form  Message  Text  O  AN  1/264 

Free-form  message  text. 

Implementation  Note: 

Use  only  if  necessary  to  transmit  a  short  remark  or  note  about  the  binary  information  being  transmitted  in 
this  transaction  set. 


Optional 


EFI03  797  Security  Technique  Code  O  ID  2/2 

Code  indicating  that  this  element  will  be  used  to  tell  an  EDI  translator  program 
which  security  tehnique  to  use. 

Implementation  Note: 

Use  any  code. 


Conditional 


EFI04  799  Version  Identifier  C  AN  1/30 

Revision  level  of  a  particular  format,  program,  technique  or  algorithm. 

Implementation  Note: 

Use  to  specify  the  version,  e.g.,  2.0, 3.2,  etc.,  of  the  program  being  used  to  transmit  the  data  in  the  following 
BIN  segment.  This  data  element  pertains  to  the  program  identifier  specified  in  EFI05. 


Optional 


EFiOS 


802  Program  Identifier 


O  AN  1/30 
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Ml  •  FURNISH 

EFI  •  ELECTRONIC  FORMAT  IDENTIFICATION 


Identifies  the  name  of  the  software  program  from  which  the  technical  data 
originates. 

Implementation  Note: 

Use  to  specify  the  application  software  program  used  to  create  the  data  being  transmitted  in  the  following 
BIN  segement,  e.g.,  TruckCad,  ClassSCad.  etc.. 


Conditional 


EFI06  799  Version  Identifier  C  AN  1/30 

Revision  level  of  a  particular  format,  program,  technique  or  algorithm. 

Implementation  Note: 

Use  to  identify  the  specific  version  of  the  interchange  standard  used  to  transmit  the  data  in  the  following  BIN 
segment.  This  data  element  pertains  to  the  interchange  format  specified  in  EFI07. 


Optional 


EFI07  801  Interchange  Format  O  AN  1/30 

Industry  or  proprietary  standard  used  to  identify  the  format  of  the  data. 

Implementation  Note: 

Use  to  enter  the  specification  number  or  description  of  the  version  noted  in  EF106.  Examples  include  MIL-D- 
28000 for  IGES  and  MIL  R-28002 for  Raster. 


Conditional 


EFI08  799  Version  Identifier  C  AN  1/30 

Revision  level  of  a  particular  format,  program,  technique  or  algorithm. 

Implementation  Note: 

Use  to  identify  the  version  of  the  program  used  to  compress  :he  data  transmitted  in  the  following  BIN 
segment.  This  data  element  pertains  to  the  compression  technique  program  specified  in  EF109. 


Optional 


Optional 


EFI09  800  Compression  Technique  O  AN  1/30 

Identifies  the  digital  data  compressbn  means  and  the  type. 

Implementation  Note: 

Use  to  identify  the  compression  method,  if  any,  applied  to  the  data  transmitted  in  the  following  BIN  segmeru. 
Examples  include  TR,  Moyer,  Fish,  etc. 

EFI10  789  Drawing  Sheet  Size  Code  O  ID  2/2 

Code  indicating  the  drawing  size  and  orientation  of  a  technical  drawing  as 
specified  and  described  in  the  current  version  of  standards  ANSI  Y14.1  and  ISO 
5457  (E).  See  the  listed  ANSI  and  ISO  standards  for  the  maximum  lengths  for 
rolled  sheets.* 

Implementation  Notes: 

1.  Use  to  specify  the  drawing  sheet  size  if  the  data  transmitted  in  the  BIN  segment  are  to  be  presented  in  a 
hard  copy  as  well  as  stored  in  the  receiver's  system. 

2.  Use  any  code. 


Optional 


EFI11  803  File  Name  O  AN  1/64 

Name  assigned  or  declared  for  a  file  or  used  by  a  program  to  identify  a  file.  Exact 
format  of  the  name  depends  on  the  computer  operating  system  being  used. 
Name  also  may  be  known  as  the  file’s  "data  set  name". 

Implementation  Note: 

Use  to  enter  the  file  name  of  the  data  to  be  transmitted. 


Not  Used 
Not  Used 
Not  Used 


EFI12 

804 

EFI13 

787 

EFI14 

788 

Block  Type 
Record  Length 
Block  Length 


O  AN  1/4 

O  N  1/15 

O  N  1/5 
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Optional 


Segment;  BIN  Binary  Data 
Level:  Detail 
Loop:  HUEFI 
Usage:  Optional 
Max  Use:  >1 

Purpose:  To  transfer  binary  data  in  a  single  data  segment  and  to  allow 

identification  of  the  end  of  the  data  segment  through  a  count.  There  is  no 
identification  of  the  internal  structure  of  the  binary  data  in  this  segment. 


Mandatory 


Mandatory 


_ Data  Element  Summary _ 

IlfF.  DATA 

PIS.  ILHWT  MAlit  _ ATTIMPIfflS 


BIN01  784  Length  of  Binary  Data 

M 

NO 

1/15 

The  length  in  integral  octets  of  the  binary  data. 

BIN02  785  Binary  Data 

M 

B 

1/10 

A  string  of  octets  whk:h  can  assume  any  binary  pattern  from  hexadecimal 

00  to 

FF. 
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841  •  FURNISH 
SE  *  TRANSACTION  SET  TRAILER 


Mandatory 


Segment:  SE  Transaction  Set  Trailer 
Level:  Summary 

Loop:  _ 

Usage:  Mandatory 
Max  Use:  1 


Purpose:  To  indicate  the  end  of  the  transaction  set  and  provide  the  count  of  the 
transmitted  segments  (including  the  beginning  (ST)  and  ending  (SE) 
segments). 

Comment:  SE  is  the  last  segment  of  each  transaction  set. 


Mandatory 


Mandatory 


_ Data  Element  Summary _ 

MF.  DATA 

OtS.  tUMBO  WAMI _ ATHMUrtS 

SE01  96  Number  of  Included  Segments  M  NO  1/10 

Total  number  of  segments  included  in  a  transaction  set  including  ST  and  SE 
segments. 

SE02  329  Transaction  Set  Control  Number  M  AN  4/9 

Identifying  control  number  that  must  be  unique  within  the  transaction  set 
functional  group  assigned  by  the  originator  for  a  transaction  set 

Implementation  Note: 

Enter  the  same  number  as  carried  in  ST02. 
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4.0  ASC  X  12  FORMS 

In  this  chapter,  applicable  ASC  X12  forms  are  presented. 


BASELINE  AS  OF:  JULY  0, 1993 


4.0. 


DEPARTMENT  OF  DEFENSE 
DRAFT  IMPLEMENTATION  CONVENTION 


Rm  •/14/K 

ASC  X12  WORK  REQUEST  FORM 
SUBMITTER  INSTRUCTIONS 


NOTE;  ALL  REQUESTS  MUST  BE  TYPED  OR  PRINTED  LEGIBLY  IN  BLACK  INK. 
INCOMPLETE  OR  ILLEGIBLE  WORK  REQUESTS  WILL  BE  RETURNED  TO  THE 
SUBMITTER. 

Submit  completed  forms  to:  Technical  Department.  ASC  X12  Secrettrtat  Data  Interchange  Standards  Assodatioa 
Inc..  1800  Diagonal  Road.  Suite  355.  Alexandria.  VA  22314-2852  or  FAX  (703)  548-5738.  Submitters  are  notified  of 
the  status  of  the  work  request  after  it  has  been  reviewed  by  X12J  Technical  Assessment  Subcommittee. 

1.  TO  USE  THIS  FORM  TO  REQUEST  A  CHANGE  TO  AN  EXISTING  STANOARD(S).  use  ONE  Work  Request 
(WR)  Form  to  list  all  changes  needed  to  meet  one  BUSINESS  REASON.  Otherwise  use  miitiple  forms.  If  more 
space  is  necessary,  numbered  attachments  may  be  used  for  contlnuatlorL 

2.  TO  USE  THIS  FORM  FOR  SUPPORTING  DATA  MAINTENANCE  FOR  A  NEW  DRAFT  STANDARD,  list  al 
information  on  ONE  form;  use  atuchments  as  necessary.  List  first  all  new  segments,  then  al  new  data 
elements/codes/code  sources.  Then  list  revisions  to  axisbng  segments  and  data  elemants/codes/code  sources: 
provide  a  business  case  for  revisions  to  existing  standards.  Then  list  any  ethers  changes  needed  (e.g..  X12.S. 

XI  2.6),  Including  justification. 

3.  TO  USE  THIS  FORM  TO  REQUEST  A  PROPOSED  NEW  X12  STANDARDS  PROJECT,  provide  the  businoss 
need  and  justification  for  the  new  project  In  Part  0.  The  WR  wiU  be  refetrsd  to  an  X12  subcommittae  for  analysis. 

ADDITIONAL  INFORMATION  FOR  COMPLETING  THIS  FORM: 

PART  A:  SUBMITTER  INFORMATION:  The  WR  may  represent  the  position  of  an  MlvUual,  Industry  group,  work 
group.  X12  subgroup,  etc.  If  the  WR  representt  the  position  of  an  X12  subcommittoe-roiatad  work  group,  the 
subcommittee  chair  must  initial  the  WR. 

PART  B:  REFERENCE  USED:  Indicate  the  version/roiease  or  edition  of  the  sMndard  you  are  using  as  a  rsference. 

PART  C:  RAMinCATIONS:  Ust  allectad  transaction  sett,  segments  and  data  siamenis,  or  other  standards.  Fora 
control  standard,  name  the  affected  page  and  section  number. 

PART  0:  BUSINESS  CASE/REASON  FOR  CHANGE:  Provide  a  cornpleta  scenario  that  describes  the  busirwea 
function/operation  that  wM  be  satbfled  by  a  change  to  the  standard.  Be  spedffc,  because  this  Mormatlon  wB 
appear  In  the  XI 2  membership  ballot  package  and  wll  be  the  only  Wonnation  that  mambars  have  on  which  to  base 
their  vote.  X12J  Technical  Assessment  Subcommittee  requires  enough  Information  to  bo  able  to  propose  an 
alternate  solution  to  the  one  provided.  If  necessary. 

PART  E:  PROPOSED  WORK:  List  the  specific  changes  being  requested.  Give  the  namos  and  aaaodatad 
identifiers  of  the  standards  segmems,  data  elements  and  codes  affected  by  the  changes.  OefMdons  for  new  codas 
and  for  industry-specific  terms  must  be  complete.  For  new  codes,  provide  a  proposed  code  and  a  code  daflnidoa 
RULES;  (i)Acronyms/abbroviations  cannot  be  added  to  the  standarda-ihey  must  be  spalad  out  (2)Providean 
expanded  code  definition  for  each  code  that  is  not  completely  seif  explanatory,  that  is.  tarms  that  are  not  In  gansral 
busineu  use  or  that  are  Industry  spedffc.  (3)  Provide  code  source  rsfersnees  for  ala9demalypubllshad(non-Xl  2) 
code  lists  cited  (use  the  Form  for  New  or  Revised  Code  Source  Reference,  page  2  of  the  form). 


BASELINE  AS  OF:  JULY  9, 1993 


4.0.3 


DEPARTMENT  OF  DEFENSE 

DRAFT  IMPtEMENTATION  CONVENTION 


_  DM  NUMBER  _ 

(Submittar  Provld*)  (S«cr«Uf1it  Only) 

ASC  X12 

WORK  REQUEST  FORM 

A.  SUBMITTER  INFORMATION: 

Submftttr  Namt _ 

Address  _ 

Phone 

Submission  represents  the  position  oh 


4.0.4  BASEUNEASOF;  JULY9,1993 


Rav  9/14/92 

Oate  Submined 


DEPARTMENT  OF  DEFENSE 
DRAFT  IMPLEMENTATION  CONVENTION 


Rm.  9/l4/«t 

WR  Foiw  Pig«  T«s  OM  NUMBER 

(Sscrslsrtit  Only) 

FORM  FOR  NEW  OR  REVISED  CODE  SOURCE  REFERENCE 
FOR  X12.3  DATA  ELEMENT  DICTIONARY 


INSTRUCTIONS:  Compieta  this  form  whtfw/sr  a  new  datt  alamant  or  data  aiamarff  coda  Is  raquastad  to  ba 
added  to  Appendix  A  of  X12.3  Data  Elamant  Dictionary,  which  rafarancas  a  coda  list  pubilshad  by  an  organization 
axtamaJ  to  X12.  Use  one  form  for  each  new  rafsranca.  This  form  may  ba  usad  to  ravisa  currant  rafarancas;  tH  out 
the  appropriata  areas  below. 


PART  1 :  REFERENCE  Cird«  i  w  2  d*iow.  it  2.  fiu  in  tn«  oi«nk. 

(1)  NEW  REFERENCE 

(2)  REVISED  REFERENCE,  Currant  rafaranca  numbar/nama 


PARTS:  REFERENCE  HTUE  only  onatourM  tor  eodM  tor  Sw  data  Nwnam.  aw  as*  awiia  as  sw  Mm  aaswaaia 

•lamant  iMfTw.  »  mw  w  irwHleN  ood— ftMuncinQ  iciwal  coda  ■oww  tor  Sw  aanw  dsM  Nwnant  SSa  meuM  asproNiww  tw  ooa» 
ddflnMon. 

REFERENCE  TITLE; 


PART  3:  DATA  ELEMENTS  USED  IN  ON*  tw  data  Namant  matanca  numaar  and  nama  aMeh  dkacta  Sia  uaar  la  Sda  eoda 
wuroa.  GNa  aw  coda  lO  (W  aaalgnad)  H  Siia  la  for  a  apaodlc  coda  of  aw  data  alamant 

USED  IN:  DENo. _ .Coda  10 _ 

PART  4:  SOURCE  ProyMaawnamaofawpMailcaitanainicnccntalnaSwcedaarafaiancad. 

PUBUSHEO  IN: 


PARTS:  AVAILABLE  FROM  GNaSwpgeilanar.droawf  oonMCLtromainomaiaMaarcanBatalnaiadociFnant 

AVAILABLE:  Nama/Altnof  _ 

Company  _ 

Address  _ 

Addrsss  _ 

Addrass/ZIP  _ /ZIP  ♦  4 _ 


PARTS:  ABSTRACT  SrlaflydaacnbaawpgMeaaan, ltipwrpeaa,andlndtaaiaidiaieadaaRoonialna. 
ABSTRACT: 


BASELINE  AS  OF:  JULY  9. 1993 


4.0.5 


4.0.6 
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DEPARTMENT  OF  DEFENSE 
DRAFT  RIPtEMENTATION  CONVENTION 


5.0  GLOSSARY 

This  chapter  cootains  ASC  XI 2-  and  DoD-specific  glossaries. 

5.1  X12  GLOSSARY 

ANSI 

American  National  Standards  Institute 


ANSI  Standard 

A  document  published  by  ANSI  that  has  been  approved  through 
the  consensus  process  of  public  announcement  and  review.  Each 
such  sundards  must  have  been  developed  by  an  ANSI  committee 
and  must  be  revisited  by  that  committee  within  S  years  for  updat¬ 
ing.  See  Draft  Standard  for  Trial  Use  (DSTU). 

Area  Transaction  Set 

A  predefined  area  within  a  transaction  set  (header,  detail,  sum¬ 
mary)  containing  segmenu  and  their  various  attributes. 

ASC  X12 

Accredited  Standards  Committee,  X12.  It  comprises  industry 
members  who  create  electronic  data  interchange  (^I)  standards 
for  submission  to  ANSI  for  subsequent  approval  and  dissemination. 

Aathcntkation 

A  mechanism  that  allows  the  receive  of  an  electronic  transmission 
to  verify  the  sender  and  the  integrity  of  the  content  of  the  trans¬ 
mission  through  the  use  of  an  electronic  "key”  or  algorithm  shared 
by  the  trading  partners.  That  algorithm  is  sometimes  referred  to 
as  an  electronic  signature. 

Compliance  Checking 

A  checking  process  that  is  used  to  ensure  that  a  transmission 
complies  with  ANSI  X12  syntax  rules. 

Conditionai  (C) 

A  data  element  requirement  designator  that  indicates  that  the 
presence  of  a  specified  data  element  is  dependent  on  the  value  or 
presence  of  other  data  elements  in  the  segment.  The  condition 
must  be  stated  and  must  be  computer  processable. 

Control  Segment 

A  segment  that  has  the  same  structure  as  a  data  segment  but  is 
used  for  transferring  control  information  for  grouping  data  seg¬ 
ments.  Control  segments  may  be  loop  control  segments  (LS/LE), 
transaction  set  control  segments  (ST/SE),  or  functional  group  con¬ 
trol  segments  (GS/GE),  defined  in  X12.6,  or  interchange  control 
segments  (ISA/EEA/TAl)  defined  in  X12.S. 


BASELINE  AS  OF:  JULY  9,1993 


5.0.1 


Data  Ekment 

The  basic  unit  of  information  in  the  EDI  stanriards  containing  a 
set  of  values  that  represent  a  singular  fact.  It  may  be  single-char¬ 
acter  codes,  literal  descriptions,  or  numeric  values. 

Data  Eleiucnt  Length 

The  range,  minimum  to  maximum,  of  the  number  of  character 
positions  available  to  represent  the  value  of  a  data  element.  A 
data  element  may  be  of  variable  length  and  ringe  from  minimum 
to  maximum  or  it  may  be  of  fixed  length  in  which  the  minimum 
is  equal  to  the  maximum. 

Data  Element  Reference  Number 

Number  assigned  to  each  data  clement  as  a  unique  identifier. 
Data  Element  Requirement  Designator 

A  code  defining  the  need  for  a  data  element  value  to  appear  in  the 
segment  if  the  segment  is  transmitted.  The  XI 2  codes  are  man¬ 
datory  (M).  optional  (O).  or  conditional  (C).  DoO  may  consider 
a  segment  “mandatory”  even  through  it  is  “optional"  by  X12 
standards. 

Data  Element  Separator 

A  unique  character  preceding  each  data  element  that  is  used  to 
ilelimit  data  elements  within  a  segment.  DoD  uses  as  the 
delimiter. 

Data  Element  Type 

A  data  element  may  be  one  of  six  types:  nunwric,  decimal, 
identifier,  string,  date,  or  time. 

Delimiters 

Two  levels  of  separators  and  a  terminator.  The  delimiters  are  an 
integral  part  of  the  transferred  data  stream.  They  are  specified  in 
the  interchange  header  and  may  not  be  used  in  a  data  element 
value  elsewhere  in  the  interchange.  From  highest  to  lowest  level, 
the  separators  and  terminator  are  segment  tenninator  and  data 
element  separator. 

DISA 

Data  Interchange  Standards  Association.  A  nonprofit  organization 
funded  by  ASC  X12  members  to  serve  as  the  Secretariat  for  XI 2. 

DSTU 

Draft  Standard  for  Trial  Use.  It  represents  a  document  approved 
for  publication  by  the  full  XI 2  committee  following  memtership 
consensus  and  subsequent  resolution  of  negative  votes.  (Fintd 
Report  of  X12  Publications  Task  Group).  The  Draft  EDI  Standard 
for  Trial  Use  document  represents  an  ASC  X12  approved  standard 
for  use  prior  to  iqjproval  by  ANSI.  See  ANSI  Standard. 
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EDI 

Electronic  data  interchange.  The  computer-application-to-com- 
puter-application  exchange  of  business  information  in  a  standard 
format. 

Electronic  Envelope 

Electronic  information  that  binds  together  a  set  of  transmitted 
documents  being  sent  from  one  sender  to  one  receiver. 

Element  Delimiter 

A  single-character  that  follows  the  segment  identifier  and  separates 
each  data  element  in  a  segment  except  the  last. 

Functional  Group 

A  group  of  one  or  more  transaction  sets  bounded  by  a  functional 
group  header  segment  and  a  functional  group  trailer  segment. 

Functional  Group  Segments  (GS/GE) 

These  segments  identify  a  specific  functional  group  of  documents 
such  as  purchase  orders. 

Industry  Conventions 

Defines  how  the  ASC  X12  standards  are  used  by  the  specific 
industry 

Industry  Guidelines 

Defines  the  EDI  environment  for  using  conventions  within  an 
industry.  It  provides  assistance  on  bow  to  implement  XI 2  stand¬ 
ards. 

Interchange  Control  Segments  (ISA/lEA) 

These  segments  identify  a  unique  interchange  being  sent  ftom  one 
sender  to  one  receiver  (see  electronic  envelope). 

Interchange  Control  Structure 

The  interchange  header  and  trailer  segments  that  envelop  one  or 
more  functional  groups  or  interchange-related  control  segments  and 
perform  the  following  functions;  (1)  defines  the  data  element 
separators  and  the  data  segment  terminators,  (2)  identifies  the 
sender  and  receiver,  (3)  provides  control  information  for  the  inter¬ 
change,  and  (4)  allows  for  authorization  and  security  information. 
(X12.5) 

Loop 

A  group  of  semantically  related  segments;  these  segments  may  be 
either  Iwunded  or  unbounded  (X12.6).  The  N1  loop  is  an  example 
of  a  loop,  which  includes  Segments  N1  to  PER  for  name  and 
address  information. 

Mandatory  (M) 

A  data  element/segment  requirement  designator  that  indicates  the 
presence  of  a  specified  data  element  is  required. 
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Mapping 

The  process  of  identifying  the  standard  data  element’s  relationship 
to  application  data  elements. 

Max  Use 

Specifies  the  maximum  number  of  times  a  segment  can  be  used  at 
the  location  in  a  transaction  set 

Message 

Entire  data  stream  including  the  outer  envelope 
Optional  (O) 

A  data  element/segment  requirement  designator  that  indicates  the 
presence  of  a  specified  data  element/segment  is  at  the  option  of 
the  sending  party  and  can  be  based  on  the  mutual  agreement  of 
the  interchange  parties. 

Qualifler 

A  data  element  that  identifies  or  defines  a  related  element,  set  of 
elements,  or  a  segment.  The  qualifier  contains  a  code  taken  from 
a  list  of  approved  codes. 

Repeating  Segment 

A  segment  that  may  be  used  more  than  once  at  a  given  location 
in  a  transaction  set  See  Max  Use. 

Security 

System  screening  that  denies  access  to  unauthorized  users  and 
protects  data  from  unauthorized  uses 

Segment 

Segments  consist  of  logically  related  data  elements  in  a  defined 
sequence.  A  data  segment  consists  of  a  segment  identifrer,  one  or 
more  data  elements  each  preceded  by  an  element  separator,  and 
a  segment  terminator. 

Segment  Directory 

Provictes  the  purpose  and  format  of  the  segments  used  in  the 
construction  of  transaction  sets.  The  directory  lists  each  segment 
by  name,  purpose,  identifier,  the  contained  data  elements  in  the 
specified  order,  and  the  requirement  designator  for  each  data 
element. 

Segment  Identifier 

A  unique  identifier  for  a  segment,  consisting  of  a  combination  of 
two  or  three  upper-case  letters  and  digits.  The  segment  identifier 
occupies  the  first-character  positions  of  the  segment  It  is  not  a 
data  element.  The  segment  identifier  in  EDIFACT  is  a  component 
data  element  —  part  of  a  composite  data  element  consisting  of  a 
segment  identifier  and  an  explicit  looping  designator. 
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Segment  Terminator 

A  unique  character  appearing  at  the  end  of  a  segment  to  indicate 
the  termination  of  the  segment,  e.g.,  N/L. 

Syntax 

The  grammar  or  rules  that  define  the  structure  of  the  EDI  standards 
(i.e.,  the  use  of  loops,  qualifiers,  etc.).  Syntax  rules  are  published 
in  ANSI  XI2.6. 

Transaction  Set 

A  document  that  unambiguously  defines,  in  the  standard  syntax, 
information  of  business  or  strategic  significance  and  consists  of  a 
header  segment,  one  or  more  data  segments  in  a  specified  order, 
and  a  trailer  segment. 

Transaction  Set  ID 

An  identifier  that  uniquely  identifies  the  transaction  set.  This 
identifier  is  the  first  data  element  of  the  transaction  set  header 
segment. 

Translation 

The  act  of  accepting  documents  in  other  than  standard  format  and 
translating  them  to  the  standard. 

Version/Release 

Identifies  the  publication  of  the  standard  being  used  for  the  genera¬ 
tion  or  the  interpretation  of  data  in  the  XI 2  standard  format.  May 
be  found  in  the  Functional  Group  Header  Segment  (GS)  and  in  the 
Interchange  Control  Header  Segment  (ISA).  See  Control  Segment 

Vies  Committee 

Voluntary  Interindustry  Communications  Standards  for  EDI. 

X12 

The  ANSI  committee  responsible  for  the  development  and  main¬ 
tenance  of  standards  for  EDI. 

X12,5 

Interchange  Control  Structure.  This  standard  provides  the  inter¬ 
change  envelope  of  a  header  and  trailer  for  the  electronic  inter¬ 
change  through  a  data  transmission,  and  it  provides  a  structure  to 
acknowledge  the  receipt  and  processing  of  this  envelope. 

X12.6 

Application  Control  Structure.  This  standard  describes  the  control 
segments  used  to  envelop  loops  of  data  segments,  transaction  sets, 
and  groups  of  related  transaction  sets. 
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5^  DoD  GLOSSARY 

AIS 

Automated  information  systems 
DUSD  (Logistics) 

Deputy  Under  Secretary  of  Defense  (Logistics) 

DES 

Data  encryption  standard 
DISA 

Defense  Information  Systems  Agency 
DLA 

Defense  Logistics  Agency 
ISA 

Interchange  control  header  identifier 
NIST 

National  Institute  of  Standards  and  Technology 
NTE 

Note  identifier 
PLUS 

Protection  of  logistics  unclassified/sensitive  systems 
UN/EDIFACT 

EDIFACT;  electronic  data  interchange  for  administration,  com¬ 
merce,  and  transport 

USD  (A  &  T) 

Under  Secretary  of  Defense  for  Acquisition  and  Technology 
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